Re: SLING-7613 - un-deprecating loginAdministrative
+1 - instead of whitelisted calls of the loginadmin call the mapping to admin could be whitelisted. Btw.the very early versions of servicemapping did allow to map to any user including admin which was used as temporary bridge until all the initial hiccups with service users were sorted out (at least by developers aware of that option - just remember because those admin mappings had thento be removed to be able to eliminate this option. Cheers Dominik Jörg Hoh schrieb am Fr. 27. Juli 2018 um 17:17: > Hi > > 2018-07-27 16:41 GMT+02:00 Jason E Bailey : > > > I may be off base here since I haven't spent much time with service users > > but couldn't this be handled by extending the Service User so that for > > specific services, the user returned is the literal admin user. > > > > i.e. rather then whitelisting the services that can use > > loginAdministrative the service user that these whitelisted services > would > > get would be the Administrator user. > > > > That means, that instead of the service-user you can configure to receive > the admin-user? I guess, that it won't change much... Instead of creating a > new service-user lazy people will use the admin. One could argue, that it's > still to easy to use an admin session. But harmonizing both approaches > would definitley help, because then a switch from a service-user to an > admin-user and vice-versa would be just a configuration change, but no code > change. > > Jörg > > -- > Cheers, > Jörg Hoh, > > http://cqdump.wordpress.com > Twitter: @joerghoh >
Re: [VOTE] Release Apache Sling App CMS version 0.9.0 and Apache Sling File Optimization 0.9.0
+1 (non binding) Eugen Stan Netdava International Mesaj original De la: jason.bai...@sas.com Trimis: 27 iulie 2018 17:59 Către: dev@sling.apache.org Răsp. la: dev@sling.apache.org Subiect: RE: [VOTE] Release Apache Sling App CMS version 0.9.0 and Apache Sling File Optimization 0.9.0 +1 (non binding) -Original Message- From: Daniel Klco [mailto:dk...@apache.org] Sent: Thursday, July 26, 2018 10:11 PM To: dev@sling.apache.org Subject: [VOTE] Release Apache Sling App CMS version 0.9.0 and Apache Sling File Optimization 0.9.0 EXTERNAL This release is for a reference application built with Apache Sling as discussed here: https://apache.markmail.org/thread/rqaj2vaex5upsf7g As well as a library for Sling to compress & optimize files stored in the Sling repository. Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1925/ You can use this UNIX script to download the release and verify the signatures: https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD Usage: sh check_staged_release.sh 1925 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours.
[jira] [Updated] (SLING-7790) Allow for synchronous installation of bundles and configurations via install hook
[ https://issues.apache.org/jira/browse/SLING-7790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Georg Henzler updated SLING-7790: - Description: Normally bundles configurations are installed asynchronously after a bundle is saved to the JCR during package installation (vault packages). This is due to the backgroundThread that the OsgiInstallerImpl is using. Since the introduction of the pauseInstallation signal node via SLING-3747, the installation of bundles and configurations is even forced to after the completed vault package installation. This behaviour also means that the package dependency can be declared, but it is not effective on "contained bundle level" but only on JCR content level. The following is not possible today: Complete Package with sub packages: * Package A (containing Bundle A) * Package B (containing Bundle B) with dependency to Bundle A If it is just a OSGi package dependency from Bundle B to Bundle A the installation order does not matter (the OSGi framework will sort it out). However if the content of Package B has a dependency to bundle A (think custom oak restrictions [1] or install hooks referenced) there will be an error. To allow for those cases and to avoid manual steps (not providing a complete package often means exactly that), it would be good to have a means to install contained bundles of a package synchronously. This can be achieved by a fairly simple install hook that "pre-installs" the contained InstallableResources with the correct digest to the OsgiInstaller. The subsequent call of sling-org-apache-sling-installer-provider-jcr will just update the already installed resource again with the same digest (which will not cause any action in the system). Obviously this mechanism should only be used where needed and only for configurations and bundles that are safe to install (bundles/configs that will never restart any of the base services). Using the install hook makes the mechanism "opt-in". [1] https://sling.apache.org/documentation/bundles/sling-oak-restrictions.html https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#pluggability was: Normally bundles configurations are installed asynchronously after a bundle is saved to the JCR during package installation (vault packages). This is due to the backgroundThread that the OsgiInstallerImpl is using. Since the introduction of the pauseInstallation signal node SLING-3747, the installation of bundles and configurations is forced to after the completed vault package installation. This behaviour also means that the package dependency can be declared, but they are not effective on "contained bundle level" but only on JCR content level. The following is not possible today: Complete Package with sub packages: * Package A (containing Bundle A) * Package B (containing Bundle B) with dependency to bundle A If it is just a OSGi package dependency from Bundle B to bundle A the installation order does not matter (the OSGi framework will sort it out). However if the content of package B has a dependency to bundle A (think custom oak restrictions [1] or install hooks referenced) there will be an error. To allow for those cases and to avoid manual steps (not providing a complete package often means exactly that), it would be good to have a means to install contained bundles of a package synchronously. This can be achieved by a fairly simple install hook that "pre-installs" the contained InstallableResources with the correct digest to the via the OsgiInstaller. The subsequent call of sling-org-apache-sling-installer-provider-jcr will just update the already installed resource again with the same digest (which will not cause any action in the system). Obviously this mechanism should only be used where needed and only for configurations and bundles that are safe to install (that will never restart any of the base services), using the install hook makes the mechanism "opt-in". [1] https://sling.apache.org/documentation/bundles/sling-oak-restrictions.html https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#pluggability > Allow for synchronous installation of bundles and configurations via install > hook > - > > Key: SLING-7790 > URL: https://issues.apache.org/jira/browse/SLING-7790 > Project: Sling > Issue Type: New Feature > Components: Installer >Reporter: Georg Henzler >Assignee: Georg Henzler >Priority: Major > > Normally bundles configurations are installed asynchronously after a bundle > is saved to the JCR during package installation (vault packages). This is due > to the backgroundThread that the OsgiInstallerImpl is using. Since the > introduction of the pauseInstallat
[jira] [Commented] (SLING-7790) Allow for synchronous installation of bundles and configurations via install hook
[ https://issues.apache.org/jira/browse/SLING-7790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559939#comment-16559939 ] Georg Henzler commented on SLING-7790: -- Created a a first version as base for discussion at https://github.com/ghenzler/org.apache.sling.installer.provider.installhook > Allow for synchronous installation of bundles and configurations via install > hook > - > > Key: SLING-7790 > URL: https://issues.apache.org/jira/browse/SLING-7790 > Project: Sling > Issue Type: New Feature > Components: Installer >Reporter: Georg Henzler >Assignee: Georg Henzler >Priority: Major > > Normally bundles configurations are installed asynchronously after a bundle > is saved to the JCR during package installation (vault packages). This is due > to the backgroundThread that the OsgiInstallerImpl is using. Since the > introduction of the pauseInstallation signal node SLING-3747, the > installation of bundles and configurations is forced to after the completed > vault package installation. This behaviour also means that the package > dependency can be declared, but they are not effective on "contained bundle > level" but only on JCR content level. The following is not possible today: > Complete Package with sub packages: > * Package A (containing Bundle A) > * Package B (containing Bundle B) with dependency to bundle A > If it is just a OSGi package dependency from Bundle B to bundle A the > installation order does not matter (the OSGi framework will sort it out). > However if the content of package B has a dependency to bundle A (think > custom oak restrictions [1] or install hooks referenced) there will be an > error. > To allow for those cases and to avoid manual steps (not providing a complete > package often means exactly that), it would be good to have a means to > install contained bundles of a package synchronously. This can be achieved by > a fairly simple install hook that "pre-installs" the contained > InstallableResources with the correct digest to the via the OsgiInstaller. > The subsequent call of sling-org-apache-sling-installer-provider-jcr will > just update the already installed resource again with the same digest (which > will not cause any action in the system). > Obviously this mechanism should only be used where needed and only for > configurations and bundles that are safe to install (that will never restart > any of the base services), using the install hook makes the mechanism > "opt-in". > [1] > https://sling.apache.org/documentation/bundles/sling-oak-restrictions.html > https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#pluggability -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-7790) Allow for synchronous installation of bundles and configurations via install hook
Georg Henzler created SLING-7790: Summary: Allow for synchronous installation of bundles and configurations via install hook Key: SLING-7790 URL: https://issues.apache.org/jira/browse/SLING-7790 Project: Sling Issue Type: New Feature Components: Installer Reporter: Georg Henzler Assignee: Georg Henzler Normally bundles configurations are installed asynchronously after a bundle is saved to the JCR during package installation (vault packages). This is due to the backgroundThread that the OsgiInstallerImpl is using. Since the introduction of the pauseInstallation signal node SLING-3747, the installation of bundles and configurations is forced to after the completed vault package installation. This behaviour also means that the package dependency can be declared, but they are not effective on "contained bundle level" but only on JCR content level. The following is not possible today: Complete Package with sub packages: * Package A (containing Bundle A) * Package B (containing Bundle B) with dependency to bundle A If it is just a OSGi package dependency from Bundle B to bundle A the installation order does not matter (the OSGi framework will sort it out). However if the content of package B has a dependency to bundle A (think custom oak restrictions [1] or install hooks referenced) there will be an error. To allow for those cases and to avoid manual steps (not providing a complete package often means exactly that), it would be good to have a means to install contained bundles of a package synchronously. This can be achieved by a fairly simple install hook that "pre-installs" the contained InstallableResources with the correct digest to the via the OsgiInstaller. The subsequent call of sling-org-apache-sling-installer-provider-jcr will just update the already installed resource again with the same digest (which will not cause any action in the system). Obviously this mechanism should only be used where needed and only for configurations and bundles that are safe to install (that will never restart any of the base services), using the install hook makes the mechanism "opt-in". [1] https://sling.apache.org/documentation/bundles/sling-oak-restrictions.html https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#pluggability -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: SLING-7613 - un-deprecating loginAdministrative
Hi 2018-07-27 16:41 GMT+02:00 Jason E Bailey : > I may be off base here since I haven't spent much time with service users > but couldn't this be handled by extending the Service User so that for > specific services, the user returned is the literal admin user. > > i.e. rather then whitelisting the services that can use > loginAdministrative the service user that these whitelisted services would > get would be the Administrator user. > That means, that instead of the service-user you can configure to receive the admin-user? I guess, that it won't change much... Instead of creating a new service-user lazy people will use the admin. One could argue, that it's still to easy to use an admin session. But harmonizing both approaches would definitley help, because then a switch from a service-user to an admin-user and vice-versa would be just a configuration change, but no code change. Jörg -- Cheers, Jörg Hoh, http://cqdump.wordpress.com Twitter: @joerghoh
RE: [VOTE] Release Apache Sling App CMS version 0.9.0 and Apache Sling File Optimization 0.9.0
+1 (non binding) -Original Message- From: Daniel Klco [mailto:dk...@apache.org] Sent: Thursday, July 26, 2018 10:11 PM To: dev@sling.apache.org Subject: [VOTE] Release Apache Sling App CMS version 0.9.0 and Apache Sling File Optimization 0.9.0 EXTERNAL This release is for a reference application built with Apache Sling as discussed here: https://apache.markmail.org/thread/rqaj2vaex5upsf7g As well as a library for Sling to compress & optimize files stored in the Sling repository. Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1925/ You can use this UNIX script to download the release and verify the signatures: https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD Usage: sh check_staged_release.sh 1925 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours.
Re: SLING-7613 - un-deprecating loginAdministrative
If this is technically possible (and I don't see why it isn't), I think this is a very elegant solution. On Fri, Jul 27, 2018 at 10:41 AM Jason E Bailey wrote: > I may be off base here since I haven't spent much time with service users > but couldn't this be handled by extending the Service User so that for > specific services, the user returned is the literal admin user. > > i.e. rather then whitelisting the services that can use > loginAdministrative the service user that these whitelisted services would > get would be the Administrator user. > > - Jason > > On Thu, Jul 19, 2018, at 5:25 AM, Bertrand Delacretaz wrote: > > Hi, > > > > On Tue, Jul 17, 2018 at 1:43 PM Justin Edelson > wrote: > > > ...Without the deprecation, how will a developer know that they need to > > > configure the whitelist? While the deprecation wasn't perfect, at > least it > > > gave the developer the sense that they were doing something which > should be > > > avoided. It is unfortunate that deprecation in Java is such a binary > > > concept, but it is what it is... > > > > I agree with Justin here, I think our intention is to say "do not use > > this method unless you really have to and you know what you are doing" > > and also "note that you have to whitelist bundles which uses this". > > > > That's not the standard meaning of a deprecated Java method, but as > > Justin says we don't want developers to miss that restriction and > > deprecation is a workable (and imperfect) way of doing that. > > > > With this in mind I suggest keeping the deprecation, creating a > > website page that explains what it actually means and linking to that > > page in the javadocs. > > > > -Bertrand >
Re: SLING-7613 - un-deprecating loginAdministrative
I may be off base here since I haven't spent much time with service users but couldn't this be handled by extending the Service User so that for specific services, the user returned is the literal admin user. i.e. rather then whitelisting the services that can use loginAdministrative the service user that these whitelisted services would get would be the Administrator user. - Jason On Thu, Jul 19, 2018, at 5:25 AM, Bertrand Delacretaz wrote: > Hi, > > On Tue, Jul 17, 2018 at 1:43 PM Justin Edelson > wrote: > > ...Without the deprecation, how will a developer know that they need to > > configure the whitelist? While the deprecation wasn't perfect, at least it > > gave the developer the sense that they were doing something which should be > > avoided. It is unfortunate that deprecation in Java is such a binary > > concept, but it is what it is... > > I agree with Justin here, I think our intention is to say "do not use > this method unless you really have to and you know what you are doing" > and also "note that you have to whitelist bundles which uses this". > > That's not the standard meaning of a deprecated Java method, but as > Justin says we don't want developers to miss that restriction and > deprecation is a workable (and imperfect) way of doing that. > > With this in mind I suggest keeping the deprecation, creating a > website page that explains what it actually means and linking to that > page in the javadocs. > > -Bertrand
Re: Markdown resource provider
> Daniel Klco wrote >> My first thought after reading the last paragraph was - Wouldn't it be >> cool if the FsResourceProvider was extensible so that specific files could >> be rendered in a specific manner, then you could add a MarkDown Handler and >> it would make it easier for other people to add custom handlers or to >> extend existing one for specific requirements. >> > > Agreed! This mechanism could be useful for XML or JSON files as well. > Imagine if one could register an XSLT handler and just have Sling serve the > rendered HTML for a dump of XML files. > That's why I mentioned the resource decorator approach - it allows you to do this, and then you're even independent of the resource provider serving the resource. The decorator approach might not be the most obvious one, but I think it does the trick and doesn't require us to add another overlapping concept. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Markdown resource provider
On Fri, Jul 27, 2018 at 3:16 PM Daniel Klco wrote: > On Fri, Jul 27, 2018, 8:46 AM Jason E Bailey wrote: ... > > Not understanding the phrase "front matter" in it's usage here > I'm assuming YAML front matter like is used in Jekyll. Correct? .. That's my understanding as well, like the first few fields at the top of https://raw.githubusercontent.com/apache/sling-site/master/src/main/jbake/content/contributing.md -Bertrand
Re: Markdown resource provider
On Fri, Jul 27, 2018, 8:46 AM Jason E Bailey wrote: > In line > > - Jason > > On Thu, Jul 26, 2018, at 7:18 PM, Robert Munteanu wrote: > > Hi, > > > > I've been toying around with a Markdown resource provider in the > > whiteboard [0]. It's very much a work-in-progress but since it does > > something - aka render Markdown files, including support for arbitrary > > Sling properties, I would like to discuss a couple of design decisions. > > > > 1. The resource is created from a markdown file in the following way: > > > > - if a first level heading is found, place the text into jcr:title > > - if a YAML front matter is found, save the properties in the resource > > properties > > Not understanding the phrase "front matter" in it's usage here > I'm assuming YAML front matter like is used in Jekyll. Correct? > > - render everything else as HTML into jcr:description > > > > I am not sure that rendering the markdown in the resource provider is > > the best way. On one hand, it keeps everything simple and does not > > require special work in the rendering script. On the other hand, > > rendering JSON/TXT with HTML inside is not that nice. > > I think it depends on the use case. From my experience there is already a > lot of text strings with HTML inside of it, so I don't see this as > something unique. Not looking at the code yet, but I assume that this is > being rendered when the resource is being requested. Which is something > that I would prefer. > > > > > 2. Only files with the 'md' extension are handled, all others are > > ignored. > > > > To generate static sites, usually markdown files are mixed with images, > > css, js files. Does it make sense to 'pass-through' these files and > > expose them as plain files? There could be some ties with the > > FsResourceProvider. Alternatively the static assets can be placed in a > > different subtree. > > > > Thoughts? > > My first thought after reading the last paragraph was - Wouldn't it be > cool if the FsResourceProvider was extensible so that specific files could > be rendered in a specific manner, then you could add a MarkDown Handler and > it would make it easier for other people to add custom handlers or to > extend existing one for specific requirements. > Agreed! This mechanism could be useful for XML or JSON files as well. Imagine if one could register an XSLT handler and just have Sling serve the rendered HTML for a dump of XML files. > > > Thanks, > > > > Robert > > > > [0]: > > > https://github.com/apache/sling-whiteboard/tree/master/mdresourceprovider >
Re: Markdown resource provider
In line - Jason On Thu, Jul 26, 2018, at 7:18 PM, Robert Munteanu wrote: > Hi, > > I've been toying around with a Markdown resource provider in the > whiteboard [0]. It's very much a work-in-progress but since it does > something - aka render Markdown files, including support for arbitrary > Sling properties, I would like to discuss a couple of design decisions. > > 1. The resource is created from a markdown file in the following way: > > - if a first level heading is found, place the text into jcr:title > - if a YAML front matter is found, save the properties in the resource > properties Not understanding the phrase "front matter" in it's usage here > - render everything else as HTML into jcr:description > > I am not sure that rendering the markdown in the resource provider is > the best way. On one hand, it keeps everything simple and does not > require special work in the rendering script. On the other hand, > rendering JSON/TXT with HTML inside is not that nice. I think it depends on the use case. From my experience there is already a lot of text strings with HTML inside of it, so I don't see this as something unique. Not looking at the code yet, but I assume that this is being rendered when the resource is being requested. Which is something that I would prefer. > > 2. Only files with the 'md' extension are handled, all others are > ignored. > > To generate static sites, usually markdown files are mixed with images, > css, js files. Does it make sense to 'pass-through' these files and > expose them as plain files? There could be some ties with the > FsResourceProvider. Alternatively the static assets can be placed in a > different subtree. > > Thoughts? My first thought after reading the last paragraph was - Wouldn't it be cool if the FsResourceProvider was extensible so that specific files could be rendered in a specific manner, then you could add a MarkDown Handler and it would make it easier for other people to add custom handlers or to extend existing one for specific requirements. > Thanks, > > Robert > > [0]: > https://github.com/apache/sling-whiteboard/tree/master/mdresourceprovider
[jira] [Commented] (SLING-7788) registerInjectActivateService() causes non-conform ServiceRegistration
[
https://issues.apache.org/jira/browse/SLING-7788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559600#comment-16559600
]
Dirk Rudolph commented on SLING-7788:
-
In the test a MyComponent implementation provides a MyService using DS
annotations and metadata provided as XML.
{code:java}
// doesn't work
context.registerInjectActivateService(new MyComponent())
// working fallback duplicating the information in the annotation
MyComponent component = new MyComponent();
MockOsgi.injectServices(component, context.bundleContext());
context.registerService(MyService.class, component);{code}
> registerInjectActivateService() causes non-conform ServiceRegistration
> --
>
> Key: SLING-7788
> URL: https://issues.apache.org/jira/browse/SLING-7788
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Affects Versions: Testing OSGi Mock 2.3.8
>Reporter: Dirk Rudolph
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> According to the OSGI R6 Spec 5.2.3 the framework has to automatically set
> the {{objectClass}} property to the service registration for the types the
> service is registered for.
> {quote}The service interface names under which a service object has been
> successfully registered are automatically added to the service's properties
> under the key objectClass. This value must be set automatically by the
> Framework and any value provided by the bundle must be overridden.
> {quote}
> This is correctly implemented in
> [MockServiceRegistration#L67|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockServiceRegistration.java#L67]
> by using the passed array of full qualified class names given to it from the
> [MockBundleContext#L101|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockBundleContext.java#L101]
> and
> [MockBundleContext#L121|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockBundleContext.java#L121]
> respectively.
> On the other hand the the execution flow of
> [registerInjectActivateService|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/context/OsgiContextImpl.java#L155]
> always causes
> [MockBundleContext#L101|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockBundleContext.java#L101]
> to be called with {{null}} as service class and so the array of services
> provided by the given object is missing for that registration.
> This causes for example the ServiceTracker according to 701.6.4.6 OSGI R6 to
> not work properly as the Filter it creates internally is referring to
> objectClass.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SLING-7789) Security bug CVE-2015-9251 with some sling dependent jars
Varun Ganesh created SLING-7789: --- Summary: Security bug CVE-2015-9251 with some sling dependent jars Key: SLING-7789 URL: https://issues.apache.org/jira/browse/SLING-7789 Project: Sling Issue Type: Bug Components: Extensions, Launchpad Affects Versions: Sling Explorer 1.0.4, Sling Explorer 1.0.2, Launchpad Builder 6 Reporter: Varun Ganesh Hi Experts, In our product we are using Sling version 6 in one of our release.(Working on Migration to Sling 10 for next versions) Recently we came across a security bug CVE-2015-9251. (CVE-2015-9251 is a vulnerability to allow an attacker to execute arbitrary code when text/javascript responses are received from cross-origin ajax requests not containing the option `dataType`. Its CVSS score is 6.1 in NVD.). To fix this an up-gradation of jQuery to versions greater than 3.0.0 is required. In our product we are using two Sling dependencies which contains jQuery. 1) org.apache.sling.launchpad.webapp - v6 (war) - contains org.apache.felix.webconsole-3.1.6.jar which internally uses jQuery v1.3.2.js. 2) org.apache.sling.extensions.explorer - v1.0.3(jar) - contains jQuery v1.4.2.min.js As part of the fix for the security bug we need to upgrade the jQuery in the jars that are mentioned above. For that we checked the latest versions for the above mentioned jars and identified that the jQuery versions are not above v3.0.0. So could you please help us in upgrading them as soon as possible. Thanks, Varun. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] Buuhuu opened a new pull request #4: SLING-7788 Create Spec conform ServiceRegistration from DS Metadata
Buuhuu opened a new pull request #4: SLING-7788 Create Spec conform ServiceRegistration from DS Metadata URL: https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/pull/4 So far the OSGI Metadata for DS components were read and added to the metadata used by the ServiceRegistration to implement its interface. Unfortunately the service implemented from the DS Metadata merged with the ones passed to the constructor were not properly exposed as service property and so made the ServiceRegistration incompatible to ServiceTracker (for example). This has been resolved by changing the order of execution in the constructor and verified with a test. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (SLING-7788) registerInjectActivateService() causes non-conform ServiceRegistration
[
https://issues.apache.org/jira/browse/SLING-7788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-7788:
Description:
According to the OSGI R6 Spec 5.2.3 the framework has to automatically set the
{{objectClass}} property to the service registration for the types the service
is registered for.
{quote}The service interface names under which a service object has been
successfully registered are automatically added to the service's properties
under the key objectClass. This value must be set automatically by the
Framework and any value provided by the bundle must be overridden.
{quote}
This is correctly implemented in
[MockServiceRegistration#L67|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockServiceRegistration.java#L67]
by using the passed array of full qualified class names given to it from the
[MockBundleContext#L101|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockBundleContext.java#L101]
and
[MockBundleContext#L121|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockBundleContext.java#L121]
respectively.
On the other hand the the execution flow of
[registerInjectActivateService|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/context/OsgiContextImpl.java#L155]
always causes
[MockBundleContext#L101|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockBundleContext.java#L101]
to be called with {{null}} as service class and so the array of services
provided by the given object is missing for that registration.
This causes for example the ServiceTracker according to 701.6.4.6 OSGI R6 to
not work properly as the Filter it creates internally is referring to
objectClass.
was:
According to the OSGI R6 Spec 5.2.3 the framework has to automatically set the
{{objectClass}} property to the service registration for the types the service
is registered for.
{quote}The service interface names under which a service object has been
successfully registered are automatically added to the service's properties
under the key objectClass. This value must be set automatically by the
Framework and any value provided by the bundle must be overridden.
{quote}
This is correctly implemented in
[MockServiceRegistration#L67|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockServiceRegistration.java#L67]
by using the passed array of full qualified class names given to it from the
[MockBundleContext#L101|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockBundleContext.java#L101]
and
[MockBundleContext#L121|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockBundleContext.java#L121]
respectively.
On the other hand the the execution flow of
[registerInjectActivateService|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/context/OsgiContextImpl.java#L155]
always causes
[MockBundleContext#L101|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockBundleContext.java#L101]
to be called with {{null}} as service class and so the array of services
provided by the given object s missing for that registration.
This causes for example the ServiceTracker according to 701.6.4.6 OSGI R6 to
not work properly as the Filter it creates internally is referring to
objectClass.
> registerInjectActivateService() causes non-conform ServiceRegistration
> --
>
> Key: SLING-7788
> URL: https://issues.apache.org/jira/browse/SLING-7788
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Affects Versions: Testing OSGi Mock 2.3.8
>Reporter: Dirk Rudolph
>Priority: Major
>
> According to the OSGI R6 Spec 5.2.3 the framework has to automatically set
> the {{objectClass}} property to the service registration for the types the
> service is registe
[jira] [Commented] (SLING-7788) registerInjectActivateService() causes non-conform ServiceRegistration
[
https://issues.apache.org/jira/browse/SLING-7788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559483#comment-16559483
]
Dirk Rudolph commented on SLING-7788:
-
I added an ignored test that illustrates the misbehaviour for the
ServiceTracker here:
[01d0eba|https://github.com/Buuhuu/sling-org-apache-sling-testing-osgi-mock/commit/01d0eba3e64b0dca06054f6a568e0dc32b165b3b]
> registerInjectActivateService() causes non-conform ServiceRegistration
> --
>
> Key: SLING-7788
> URL: https://issues.apache.org/jira/browse/SLING-7788
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Affects Versions: Testing OSGi Mock 2.3.8
>Reporter: Dirk Rudolph
>Priority: Major
>
> According to the OSGI R6 Spec 5.2.3 the framework has to automatically set
> the {{objectClass}} property to the service registration for the types the
> service is registered for.
> {quote}The service interface names under which a service object has been
> successfully registered are automatically added to the service's properties
> under the key objectClass. This value must be set automatically by the
> Framework and any value provided by the bundle must be overridden.
> {quote}
> This is correctly implemented in
> [MockServiceRegistration#L67|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockServiceRegistration.java#L67]
> by using the passed array of full qualified class names given to it from the
> [MockBundleContext#L101|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockBundleContext.java#L101]
> and
> [MockBundleContext#L121|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockBundleContext.java#L121]
> respectively.
> On the other hand the the execution flow of
> [registerInjectActivateService|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/context/OsgiContextImpl.java#L155]
> always causes
> [MockBundleContext#L101|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockBundleContext.java#L101]
> to be called with {{null}} as service class and so the array of services
> provided by the given object s missing for that registration.
> This causes for example the ServiceTracker according to 701.6.4.6 OSGI R6 to
> not work properly as the Filter it creates internally is referring to
> objectClass.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SLING-7788) registerInjectActivateService() causes non-conform ServiceRegistration
Dirk Rudolph created SLING-7788:
---
Summary: registerInjectActivateService() causes non-conform
ServiceRegistration
Key: SLING-7788
URL: https://issues.apache.org/jira/browse/SLING-7788
Project: Sling
Issue Type: Bug
Components: Testing
Affects Versions: Testing OSGi Mock 2.3.8
Reporter: Dirk Rudolph
According to the OSGI R6 Spec 5.2.3 the framework has to automatically set the
{{objectClass}} property to the service registration for the types the service
is registered for.
{quote}The service interface names under which a service object has been
successfully registered are automatically added to the service's properties
under the key objectClass. This value must be set automatically by the
Framework and any value provided by the bundle must be overridden.
{quote}
This is correctly implemented in
[MockServiceRegistration#L67|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockServiceRegistration.java#L67]
by using the passed array of full qualified class names given to it from the
[MockBundleContext#L101|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockBundleContext.java#L101]
and
[MockBundleContext#L121|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockBundleContext.java#L121]
respectively.
On the other hand the the execution flow of
[registerInjectActivateService|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/context/OsgiContextImpl.java#L155]
always causes
[MockBundleContext#L101|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/5adc8b7eb2c2bbffdd422959388e8c998684eda0/src/main/java/org/apache/sling/testing/mock/osgi/MockBundleContext.java#L101]
to be called with {{null}} as service class and so the array of services
provided by the given object s missing for that registration.
This causes for example the ServiceTracker according to 701.6.4.6 OSGI R6 to
not work properly as the Filter it creates internally is referring to
objectClass.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-7787) Support official JSON format for configurations
[ https://issues.apache.org/jira/browse/SLING-7787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559426#comment-16559426 ] Bertrand Delacretaz commented on SLING-7787: Great, thank you! I did remember suboptimal linkability in earlier versions of the spec so it's great to have that. > Support official JSON format for configurations > --- > > Key: SLING-7787 > URL: https://issues.apache.org/jira/browse/SLING-7787 > Project: Sling > Issue Type: Improvement > Components: Installer >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Installer Configuration Factory 1.2.0, Installer Core > 3.8.14 > > > The OSGi R7 configurator specification defines a JSON format for > configurations which is an official format to represent an OSGi configuration > as text. > We should support this format -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-7787) Support official JSON format for configurations
[ https://issues.apache.org/jira/browse/SLING-7787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559417#comment-16559417 ] Carsten Ziegeler commented on SLING-7787: - Another nice thing of the R7 release, everything is now available as html to be linked, so here you go: https://osgi.org/specification/osgi.cmpn/7.0.0/service.configurator.html > Support official JSON format for configurations > --- > > Key: SLING-7787 > URL: https://issues.apache.org/jira/browse/SLING-7787 > Project: Sling > Issue Type: Improvement > Components: Installer >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Installer Configuration Factory 1.2.0, Installer Core > 3.8.14 > > > The OSGi R7 configurator specification defines a JSON format for > configurations which is an official format to represent an OSGi configuration > as text. > We should support this format -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Markdown resource provider
Hi. That's cool indeed! What about using (potentially different) HTL scripts and create a Sling model that reads the raw markdown? - Andrei On Fri, Jul 27, 2018, 08:07 Bertrand Delacretaz wrote: > Hi Robert, > > Cool stuff! > > On Fri, Jul 27, 2018 at 1:18 AM Robert Munteanu > wrote: > ... > > - render everything else as HTML into jcr:description ... > > I think rendering is a good idea but how about using a more specific > property name? > > Maybe use sling:markdownBody and sling:renderedHtmlBody with the > latter being lazily rendered? Or maybe more concise names, but > specific names would help avoid surprises IMO. > > > ...To generate static sites, usually markdown files are mixed with > images, > > css, js files. Does it make sense to 'pass-through' these files and > > expose them as plain files?... > > I think so, and maybe Carsten's decorator approach helps achieve that. > > -Bertrand >
[jira] [Commented] (SLING-7787) Support official JSON format for configurations
[ https://issues.apache.org/jira/browse/SLING-7787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559380#comment-16559380 ] Bertrand Delacretaz commented on SLING-7787: Cool - do you have a link to that spec? > Support official JSON format for configurations > --- > > Key: SLING-7787 > URL: https://issues.apache.org/jira/browse/SLING-7787 > Project: Sling > Issue Type: Improvement > Components: Installer >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Installer Configuration Factory 1.2.0, Installer Core > 3.8.14 > > > The OSGi R7 configurator specification defines a JSON format for > configurations which is an official format to represent an OSGi configuration > as text. > We should support this format -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-7786) Use R7 configuration admin supporting named factory configurations
[ https://issues.apache.org/jira/browse/SLING-7786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559351#comment-16559351 ] Carsten Ziegeler commented on SLING-7786: - I've changed the code in rev 2c53016 to use the named factory configurations. With this we can remove a lot of special handling from the code. However, this code will currently not correctly handle configurations processed by previous versions. This will be the next step > Use R7 configuration admin supporting named factory configurations > -- > > Key: SLING-7786 > URL: https://issues.apache.org/jira/browse/SLING-7786 > Project: Sling > Issue Type: Improvement > Components: Installer >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Installer Configuration Factory 1.2.0 > > > R7 contains special support for factory configurations by providing a name > (alias) which makes managed the alias in our code obsolete. > We should switch to this new api - but we also need to handle updating an > existing instance -- This message was sent by Atlassian JIRA (v7.6.3#76005)
