[jira] [Created] (SLING-8117) Add support to read/write of ACE restrictions from REST
Eric Norman created SLING-8117: -- Summary: Add support to read/write of ACE restrictions from REST Key: SLING-8117 URL: https://issues.apache.org/jira/browse/SLING-8117 Project: Sling Issue Type: New Feature Affects Versions: JCR Jackrabbit Access Manager 3.0.2, JCR ContentLoader 2.2.6, JCR Base 3.0.4 Reporter: Eric Norman Assignee: Eric Norman Fix For: JCR Base 3.0.6, JCR Jackrabbit Access Manager 3.0.4, JCR ContentLoader 2.2.8 Support for read/write of restrictions on the ACE has not yet been implemented in the sling jackrabbit.accessmanager REST operations (and elsewhere). However it looks like adding support for read/write of ACE restrictions would not be too difficult and it looks like it could be useful to the community. It looks like changes would be needed in a few bundles, specifically these: 1. org.apache.sling.jcr.base a) Changes to the AccessControlUtil addEntry/replaceAccessControlEntry methods to support passing in and processing of restrictions 2. org.apache.sling.jcr.jackrabbit.accessmanager a) ModifyAce - changes to process posted "restriction" parameters to be set b) GetAcl/GetEffectiveAcl servlets - changes to return the restriction values in the returned JSON c) PrivilegesInfo - add methods to read the declared restrictions to be used from scripts who are interested in such things 3. org.apache.sling.jcr.contentloader a) Changes to the ContentCreator and JsonReader to support reading restrictions from the JSON and applying them while loading content into the repository 4. Plus some automated tests and updated documentation... SLING-6422 appears to have already added support for setting restrictions for the repoinit style of ACE initialization -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-8117) Add support to read/write ACE restrictions from REST
[ https://issues.apache.org/jira/browse/SLING-8117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Norman updated SLING-8117: --- Description: Support for read/write of restrictions on the ACE has not yet been implemented in the sling jackrabbit.accessmanager REST operations (and elsewhere). However it looks like adding support for read/write of ACE restrictions would not be too difficult and it looks like it could be useful to the community. It looks like changes would be needed in a few bundles, specifically these: 1. org.apache.sling.jcr.base a) Changes to the AccessControlUtil addEntry/replaceAccessControlEntry methods to support passing in and processing of restrictions 2. org.apache.sling.jcr.jackrabbit.accessmanager a) ModifyAce - changes to process posted "restriction" parameters to be set b) GetAcl/GetEffectiveAcl servlets - changes to return the declared restriction values in the returned JSON c) PrivilegesInfo - add methods to read the declared restrictions to be used from scripts who are interested in such things 3. org.apache.sling.jcr.contentloader a) Changes to the ContentCreator and JsonReader to support reading restrictions from the JSON and applying them while loading content into the repository 4. Plus some automated tests and updated documentation... SLING-6422 appears to have already added support for setting restrictions for the repoinit style of ACE initialization was: Support for read/write of restrictions on the ACE has not yet been implemented in the sling jackrabbit.accessmanager REST operations (and elsewhere). However it looks like adding support for read/write of ACE restrictions would not be too difficult and it looks like it could be useful to the community. It looks like changes would be needed in a few bundles, specifically these: 1. org.apache.sling.jcr.base a) Changes to the AccessControlUtil addEntry/replaceAccessControlEntry methods to support passing in and processing of restrictions 2. org.apache.sling.jcr.jackrabbit.accessmanager a) ModifyAce - changes to process posted "restriction" parameters to be set b) GetAcl/GetEffectiveAcl servlets - changes to return the restriction values in the returned JSON c) PrivilegesInfo - add methods to read the declared restrictions to be used from scripts who are interested in such things 3. org.apache.sling.jcr.contentloader a) Changes to the ContentCreator and JsonReader to support reading restrictions from the JSON and applying them while loading content into the repository 4. Plus some automated tests and updated documentation... SLING-6422 appears to have already added support for setting restrictions for the repoinit style of ACE initialization > Add support to read/write ACE restrictions from REST > > > Key: SLING-8117 > URL: https://issues.apache.org/jira/browse/SLING-8117 > Project: Sling > Issue Type: New Feature >Affects Versions: JCR Base 3.0.4, JCR ContentLoader 2.2.6, JCR Jackrabbit > Access Manager 3.0.2 >Reporter: Eric Norman >Assignee: Eric Norman >Priority: Major > Fix For: JCR Base 3.0.6, JCR Jackrabbit Access Manager 3.0.4, JCR > ContentLoader 2.2.8 > > > Support for read/write of restrictions on the ACE has not yet been > implemented in the sling jackrabbit.accessmanager REST operations (and > elsewhere). > > However it looks like adding support for read/write of ACE restrictions > would not be too difficult and it looks like it could be useful to the > community. > > It looks like changes would be needed in a few bundles, specifically these: > > 1. org.apache.sling.jcr.base > a) Changes to the AccessControlUtil addEntry/replaceAccessControlEntry > methods to support passing in and processing of restrictions > 2. org.apache.sling.jcr.jackrabbit.accessmanager > a) ModifyAce - changes to process posted "restriction" parameters to be > set > b) GetAcl/GetEffectiveAcl servlets - changes to return the declared > restriction values in the returned JSON > c) PrivilegesInfo - add methods to read the declared restrictions to be > used from scripts who are interested in such things > 3. org.apache.sling.jcr.contentloader > a) Changes to the ContentCreator and JsonReader to support reading > restrictions from the JSON and applying them while loading content into the > repository > 4. Plus some automated tests and updated documentation... > > SLING-6422 appears to have already added support for setting restrictions > for the repoinit style of ACE initialization > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-8117) Add support to read/write ACE restrictions from REST
[ https://issues.apache.org/jira/browse/SLING-8117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Norman updated SLING-8117: --- Summary: Add support to read/write ACE restrictions from REST (was: Add support to read/write of ACE restrictions from REST) > Add support to read/write ACE restrictions from REST > > > Key: SLING-8117 > URL: https://issues.apache.org/jira/browse/SLING-8117 > Project: Sling > Issue Type: New Feature >Affects Versions: JCR Base 3.0.4, JCR ContentLoader 2.2.6, JCR Jackrabbit > Access Manager 3.0.2 >Reporter: Eric Norman >Assignee: Eric Norman >Priority: Major > Fix For: JCR Base 3.0.6, JCR Jackrabbit Access Manager 3.0.4, JCR > ContentLoader 2.2.8 > > > Support for read/write of restrictions on the ACE has not yet been > implemented in the sling jackrabbit.accessmanager REST operations (and > elsewhere). > > However it looks like adding support for read/write of ACE restrictions would > not be too difficult and it looks like it could be useful to the community. > > It looks like changes would be needed in a few bundles, specifically these: > > 1. org.apache.sling.jcr.base > a) Changes to the AccessControlUtil addEntry/replaceAccessControlEntry > methods to support passing in and processing of restrictions > 2. org.apache.sling.jcr.jackrabbit.accessmanager > a) ModifyAce - changes to process posted "restriction" parameters to be > set > b) GetAcl/GetEffectiveAcl servlets - changes to return the restriction > values in the returned JSON > c) PrivilegesInfo - add methods to read the declared restrictions to be > used from scripts who are interested in such things > 3. org.apache.sling.jcr.contentloader > a) Changes to the ContentCreator and JsonReader to support reading > restrictions from the JSON and applying them while loading content into the > repository > 4. Plus some automated tests and updated documentation... > > SLING-6422 appears to have already added support for setting restrictions for > the repoinit style of ACE initialization > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [DISCUSS] [POTENTIALLY-BREAKING] implementing the Osgi Converter
Agreed on being careful, which is why I brought this up.
The reasons to move over are:
It provides a well documented set of features that is comprehensive and wider
then any implementation we currently have.
https://osgi.org/specification/osgi.cmpn/7.0.0/util.converter.html
An example being :
List result = valueMap.get("multiProperty",new
TypeReference>() {});
Additionally it would provide a level of consistency that we don't currently
have. Because we don't really have "an" implementation of conversion. We leave
conversion up to the ValueMap implementations and so far that can be different.
In fact, while working on this, I discovered that the ValueMapDecorator will
return different results depending on whether you've wrapped a ValueMap or a
non-ValueMap. Because the ObjectConverter class that we created internally will
return an empty array if a conversion fails versus the ValueMap which will
return null.
*NOTE* nothing is at risk by implementing default methods on the ValueMap
because everything currently implements their own version of those methods. The
risk only comes out if an existing ValueMap implementation defaults to the
default method. Or if a new ValueMap implementation is created, which at that
point, it shouldn't be a problem.
- Jason
On Fri, Nov 16, 2018, at 11:42 AM, Robert Munteanu wrote:
> Hi Jason,
>
> On Fri, 2018-11-16 at 11:26 -0500, Jason E Bailey wrote:
> > As part of
> > https://issues.apache.org/jira/browse/SLING-8116
> >
> > Which came about in the comments for
> > https://issues.apache.org/jira/browse/SLING-7934
> >
> > I discovered that the Converter works differently then our current
> > rules for handling conversions in the ValueMap.
> >
> > Supports conversions to an array of primitive types
> > valueMap.put("prop1", new String[] { "12", "2" });
> > valueMap.get("prop1", int[].class) -> returns a populated int[]
> >
> > Supports arrays to scalar
> > valueMap.put("prop1", new String[] { "12", "2" });
> > valueMap.get("prop1", int.class) -> returns the Integer 12
> >
> > These are just the two I have identified. There is mostly likely a
> > few more subtle differences on top of this.
> > After reviewing the Converter, I believe that this would be an
> > invaluable addition to the framework, but that comes with a cost of
> > handing off the rules of conversion to a separate utility.
> >
> > If anyone has issues with this, say it now.
>
> I have nothing against changing the underlying implementation.
>
> But we have to be _very_ careful with any kind of behaviour change. As
> a general rule we aim to never break backwards compatibility unless
> there is a very good reason for it.
>
> What would be the reasons for moving to the converter from our own
> implementation?
>
> Thanks,
>
> Robert
>
[jira] [Resolved] (SLING-8112) Feature IO ArtifactManagerConfig does not properly access local repository on Windows
[
https://issues.apache.org/jira/browse/SLING-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls resolved SLING-8112.
---
Resolution: Fixed
[~rombert], ok - resolving for now. Please reopen if it isn't fixed in the end.
> Feature IO ArtifactManagerConfig does not properly access local repository on
> Windows
> -
>
> Key: SLING-8112
> URL: https://issues.apache.org/jira/browse/SLING-8112
> Project: Sling
> Issue Type: Bug
> Components: Feature Model
>Reporter: Robert Munteanu
>Assignee: Karl Pauls
>Priority: Critical
> Fix For: Feature Model IO 0.2.2
>
>
> I've received reports that on Windows the local repository is not taken into
> account, and it would see that FTP(??) access is attempted
> {noformat}Artifact Repositories: [file://C:\Users\XXX/.m2/repository,
> https://repo.maven.apache.org/maven2,
> https://repository.apache.org/content/groups/snapshots]
> [INFO] Assembling provisioning model...
> [INFO] Artifact not found in one repository
> java.net.ConnectException: Connection timed out: connect
> at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method)
> at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source)
> at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)
> at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source)
> at java.net.AbstractPlainSocketImpl.connect(Unknown Source)
> at java.net.PlainSocketImpl.connect(Unknown Source)
> at java.net.Socket.connect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.doConnect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.tryConnect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.connect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.connect(Unknown Source)
> at sun.net.www.protocol.ftp.FtpURLConnection.connect(Unknown Source)
> at
> org.apache.sling.feature.io.file.ArtifactManager$DefaultArtifactHandler.getArtifact(ArtifactManager.java:334)
> at
> org.apache.sling.feature.io.file.ArtifactManager.getArtifactHandler(ArtifactManager.java:188)
> at
> org.apache.sling.feature.launcher.impl.FeatureProcessor.createApplication(FeatureProcessor.java:99)
> at org.apache.sling.feature.launcher.impl.Main.assemble(Main.java:315)
> at org.apache.sling.feature.launcher.impl.Main.main(Main.java:222){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [DISCUSS] [POTENTIALLY-BREAKING] implementing the Osgi Converter
Hi Jason,
On Fri, 2018-11-16 at 11:26 -0500, Jason E Bailey wrote:
> As part of
> https://issues.apache.org/jira/browse/SLING-8116
>
> Which came about in the comments for
> https://issues.apache.org/jira/browse/SLING-7934
>
> I discovered that the Converter works differently then our current
> rules for handling conversions in the ValueMap.
>
> Supports conversions to an array of primitive types
> valueMap.put("prop1", new String[] { "12", "2" });
> valueMap.get("prop1", int[].class) -> returns a populated int[]
>
> Supports arrays to scalar
> valueMap.put("prop1", new String[] { "12", "2" });
> valueMap.get("prop1", int.class) -> returns the Integer 12
>
> These are just the two I have identified. There is mostly likely a
> few more subtle differences on top of this.
> After reviewing the Converter, I believe that this would be an
> invaluable addition to the framework, but that comes with a cost of
> handing off the rules of conversion to a separate utility.
>
> If anyone has issues with this, say it now.
I have nothing against changing the underlying implementation.
But we have to be _very_ careful with any kind of behaviour change. As
a general rule we aim to never break backwards compatibility unless
there is a very good reason for it.
What would be the reasons for moving to the converter from our own
implementation?
Thanks,
Robert
[jira] [Commented] (SLING-8112) Feature IO ArtifactManagerConfig does not properly access local repository on Windows
[
https://issues.apache.org/jira/browse/SLING-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689646#comment-16689646
]
Robert Munteanu commented on SLING-8112:
[~karlpauls] - I tested on a Windows VM and the launcher does not seem to crash
... so I guess that's good. It also seems to find artifacts locally.
> Feature IO ArtifactManagerConfig does not properly access local repository on
> Windows
> -
>
> Key: SLING-8112
> URL: https://issues.apache.org/jira/browse/SLING-8112
> Project: Sling
> Issue Type: Bug
> Components: Feature Model
>Reporter: Robert Munteanu
>Assignee: Karl Pauls
>Priority: Critical
> Fix For: Feature Model IO 0.2.2
>
>
> I've received reports that on Windows the local repository is not taken into
> account, and it would see that FTP(??) access is attempted
> {noformat}Artifact Repositories: [file://C:\Users\XXX/.m2/repository,
> https://repo.maven.apache.org/maven2,
> https://repository.apache.org/content/groups/snapshots]
> [INFO] Assembling provisioning model...
> [INFO] Artifact not found in one repository
> java.net.ConnectException: Connection timed out: connect
> at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method)
> at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source)
> at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)
> at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source)
> at java.net.AbstractPlainSocketImpl.connect(Unknown Source)
> at java.net.PlainSocketImpl.connect(Unknown Source)
> at java.net.Socket.connect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.doConnect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.tryConnect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.connect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.connect(Unknown Source)
> at sun.net.www.protocol.ftp.FtpURLConnection.connect(Unknown Source)
> at
> org.apache.sling.feature.io.file.ArtifactManager$DefaultArtifactHandler.getArtifact(ArtifactManager.java:334)
> at
> org.apache.sling.feature.io.file.ArtifactManager.getArtifactHandler(ArtifactManager.java:188)
> at
> org.apache.sling.feature.launcher.impl.FeatureProcessor.createApplication(FeatureProcessor.java:99)
> at org.apache.sling.feature.launcher.impl.Main.assemble(Main.java:315)
> at org.apache.sling.feature.launcher.impl.Main.main(Main.java:222){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[DISCUSS] [POTENTIALLY-BREAKING] implementing the Osgi Converter
As part of
https://issues.apache.org/jira/browse/SLING-8116
Which came about in the comments for
https://issues.apache.org/jira/browse/SLING-7934
I discovered that the Converter works differently then our current rules for
handling conversions in the ValueMap.
Supports conversions to an array of primitive types
valueMap.put("prop1", new String[] { "12", "2" });
valueMap.get("prop1", int[].class) -> returns a populated int[]
Supports arrays to scalar
valueMap.put("prop1", new String[] { "12", "2" });
valueMap.get("prop1", int.class) -> returns the Integer 12
These are just the two I have identified. There is mostly likely a few more
subtle differences on top of this.
After reviewing the Converter, I believe that this would be an invaluable
addition to the framework, but that comes with a cost of handing off the rules
of conversion to a separate utility.
If anyone has issues with this, say it now.
- Jason
[jira] [Commented] (SLING-8112) Feature IO ArtifactManagerConfig does not properly access local repository on Windows
[
https://issues.apache.org/jira/browse/SLING-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689611#comment-16689611
]
Robert Munteanu commented on SLING-8112:
[~karlpauls] - I don't run on Windows but I'll try to get this validated
somehow.
> Feature IO ArtifactManagerConfig does not properly access local repository on
> Windows
> -
>
> Key: SLING-8112
> URL: https://issues.apache.org/jira/browse/SLING-8112
> Project: Sling
> Issue Type: Bug
> Components: Feature Model
>Reporter: Robert Munteanu
>Assignee: Karl Pauls
>Priority: Critical
> Fix For: Feature Model IO 0.2.2
>
>
> I've received reports that on Windows the local repository is not taken into
> account, and it would see that FTP(??) access is attempted
> {noformat}Artifact Repositories: [file://C:\Users\XXX/.m2/repository,
> https://repo.maven.apache.org/maven2,
> https://repository.apache.org/content/groups/snapshots]
> [INFO] Assembling provisioning model...
> [INFO] Artifact not found in one repository
> java.net.ConnectException: Connection timed out: connect
> at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method)
> at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source)
> at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)
> at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source)
> at java.net.AbstractPlainSocketImpl.connect(Unknown Source)
> at java.net.PlainSocketImpl.connect(Unknown Source)
> at java.net.Socket.connect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.doConnect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.tryConnect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.connect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.connect(Unknown Source)
> at sun.net.www.protocol.ftp.FtpURLConnection.connect(Unknown Source)
> at
> org.apache.sling.feature.io.file.ArtifactManager$DefaultArtifactHandler.getArtifact(ArtifactManager.java:334)
> at
> org.apache.sling.feature.io.file.ArtifactManager.getArtifactHandler(ArtifactManager.java:188)
> at
> org.apache.sling.feature.launcher.impl.FeatureProcessor.createApplication(FeatureProcessor.java:99)
> at org.apache.sling.feature.launcher.impl.Main.assemble(Main.java:315)
> at org.apache.sling.feature.launcher.impl.Main.main(Main.java:222){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-8116) ValueMap - implement default methods using OSGI Converter
[ https://issues.apache.org/jira/browse/SLING-8116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason E Bailey updated SLING-8116: -- Summary: ValueMap - implement default methods using OSGI Converter (was: ValueMap - implement default methods using Osgi Converter) > ValueMap - implement default methods using OSGI Converter > - > > Key: SLING-8116 > URL: https://issues.apache.org/jira/browse/SLING-8116 > Project: Sling > Issue Type: Improvement >Reporter: Jason E Bailey >Priority: Major > > Implement default methods in the ValueMap interface that leverages the OSGi > Converter > see > [https://osgi.org/specification/osgi.cmpn/7.0.0/util.converter.html] > Once this is implemented, custom implementations of the ValueMap interface > can start being removed, where appropriate, so that a consistent and > comprehensive conversion of properties occur. We can then add new Rules to > the Converter to allow features to be populated to all ValueMap > implementations. > > To implement this, the following will also need to happen > * The Converter bundle will need to be added as a required bundle > ** Various scripts that define the minimum needed set of bundles will need > to be updated > * Communication on the difference in behaviour between the current ValueMap > and the ValueMap with Converter > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-8116) ValueMap - implement default methods using Osgi Converter
Jason E Bailey created SLING-8116: - Summary: ValueMap - implement default methods using Osgi Converter Key: SLING-8116 URL: https://issues.apache.org/jira/browse/SLING-8116 Project: Sling Issue Type: Improvement Reporter: Jason E Bailey Implement default methods in the ValueMap interface that leverages the OSGi Converter see [https://osgi.org/specification/osgi.cmpn/7.0.0/util.converter.html] Once this is implemented, custom implementations of the ValueMap interface can start being removed, where appropriate, so that a consistent and comprehensive conversion of properties occur. We can then add new Rules to the Converter to allow features to be populated to all ValueMap implementations. To implement this, the following will also need to happen * The Converter bundle will need to be added as a required bundle ** Various scripts that define the minimum needed set of bundles will need to be updated * Communication on the difference in behaviour between the current ValueMap and the ValueMap with Converter -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-6593) sling pipes vault install hook
[ https://issues.apache.org/jira/browse/SLING-6593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Peltier updated SLING-6593: --- Component/s: pipes > sling pipes vault install hook > -- > > Key: SLING-6593 > URL: https://issues.apache.org/jira/browse/SLING-6593 > Project: Sling > Issue Type: New Feature > Components: Extensions, pipes >Affects Versions: Pipes 1.0.4 >Reporter: Nicolas Peltier >Priority: Major > > executing pipes in a repeatable fashion for now requires a script to curl it. > An elegant way would be to have the pipe configuration together with an > install hook in a package, executing it once the package is installed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-7995) [pipes] Manifold pipe not registered in PlumberServlet
[ https://issues.apache.org/jira/browse/SLING-7995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Peltier updated SLING-7995: --- Component/s: pipes > [pipes] Manifold pipe not registered in PlumberServlet > -- > > Key: SLING-7995 > URL: https://issues.apache.org/jira/browse/SLING-7995 > Project: Sling > Issue Type: Bug > Components: Extensions, pipes >Affects Versions: pipes 3.0.2 >Reporter: Stefan Popescu >Priority: Major > Fix For: pipes 3.1.0 > > > Can't start a root Manifold pipe via http, as the type is not registered with > PlumberServlet. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-7995) Manifold pipe not registered in PlumberServlet
[ https://issues.apache.org/jira/browse/SLING-7995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Peltier updated SLING-7995: --- Summary: Manifold pipe not registered in PlumberServlet (was: [pipes] Manifold pipe not registered in PlumberServlet) > Manifold pipe not registered in PlumberServlet > -- > > Key: SLING-7995 > URL: https://issues.apache.org/jira/browse/SLING-7995 > Project: Sling > Issue Type: Bug > Components: Extensions, pipes >Affects Versions: pipes 3.0.2 >Reporter: Stefan Popescu >Priority: Major > Fix For: pipes 3.1.0 > > > Can't start a root Manifold pipe via http, as the type is not registered with > PlumberServlet. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-6122) Sling Pipes javadoc fails
[ https://issues.apache.org/jira/browse/SLING-6122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Peltier updated SLING-6122: --- Component/s: pipes > Sling Pipes javadoc fails > - > > Key: SLING-6122 > URL: https://issues.apache.org/jira/browse/SLING-6122 > Project: Sling > Issue Type: Bug > Components: Extensions, pipes >Reporter: Nicolas Peltier >Assignee: Oliver Lietz >Priority: Major > Fix For: Pipes 0.0.10 > > Attachments: SLING-6122.patch > > > sling pipes javadoc fails, preventing release to be done -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-8115) pipes log should mention execution time
Nicolas Peltier created SLING-8115:
--
Summary: pipes log should mention execution time
Key: SLING-8115
URL: https://issues.apache.org/jira/browse/SLING-8115
Project: Sling
Issue Type: Improvement
Components: pipes
Affects Versions: pipes 3.0.2
Reporter: Nicolas Peltier
while we can make an operation between start and end, it does not cost much and
would be handy to have total execution time in the last line,
so something like {{done executing in 12931s}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-7772) add other scripting options for pipe expressions
[ https://issues.apache.org/jira/browse/SLING-7772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Peltier updated SLING-7772: --- Component/s: pipes > add other scripting options for pipe expressions > > > Key: SLING-7772 > URL: https://issues.apache.org/jira/browse/SLING-7772 > Project: Sling > Issue Type: Improvement > Components: Extensions, pipes >Affects Versions: pipes 2.0.2 >Reporter: Nicolas Peltier >Priority: Major > > nashorn is being deprecated (http://openjdk.java.net/jeps/335). There might > be another option soon, that will be another dependency. > Thinking about it, we should provide an option for script in pipe expression > (which should be fairly easy to do). And may be thinking of changing the > default script engine not to be JS anymore but something that does not need > dependency installed, popular and performant -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (SLING-7995) Manifold pipe not registered in PlumberServlet
[ https://issues.apache.org/jira/browse/SLING-7995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Peltier reassigned SLING-7995: -- Assignee: Nicolas Peltier > Manifold pipe not registered in PlumberServlet > -- > > Key: SLING-7995 > URL: https://issues.apache.org/jira/browse/SLING-7995 > Project: Sling > Issue Type: Bug > Components: Extensions, pipes >Affects Versions: pipes 3.0.2 >Reporter: Stefan Popescu >Assignee: Nicolas Peltier >Priority: Major > Fix For: pipes 3.1.0 > > > Can't start a root Manifold pipe via http, as the type is not registered with > PlumberServlet. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-7992) make package pipe folding its filters
[
https://issues.apache.org/jira/browse/SLING-7992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Peltier updated SLING-7992:
---
Component/s: pipes
> make package pipe folding its filters
> -
>
> Key: SLING-7992
> URL: https://issues.apache.org/jira/browse/SLING-7992
> Project: Sling
> Issue Type: Improvement
> Components: Extensions, pipes
>Affects Versions: pipes 3.0.2
>Reporter: Nicolas Peltier
>Priority: Major
> Fix For: pipes 3.1.0
>
>
> packaging resources about to change is pretty handy, but filters are not
> meant to be used for each single resource to save.
> Would be nice to have something like {{maxFilters}} and {{reductionDepth}}
> that transforms at best following set, with {{maxFilters=1}} and
> {{reductionDepth=3}}
> - /content/foo/bar/1
> - /content/foo/bar/2
> in
> - /content/foo/bar
> if not possible to satisfy the constraints, it just does nothing
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-7993) create some karate tests for pipes http api integration tests
[ https://issues.apache.org/jira/browse/SLING-7993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Peltier updated SLING-7993: --- Component/s: pipes > create some karate tests for pipes http api integration tests > - > > Key: SLING-7993 > URL: https://issues.apache.org/jira/browse/SLING-7993 > Project: Sling > Issue Type: Improvement > Components: Extensions, pipes >Affects Versions: pipes 3.0.2 >Reporter: Nicolas Peltier >Priority: Major > Fix For: pipes 3.1.0 > > > would be nice to have clear and "documenting" karate tests of pipes http API -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-7994) add skipExecution flag to pipes
[ https://issues.apache.org/jira/browse/SLING-7994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Peltier updated SLING-7994: --- Component/s: pipes > add skipExecution flag to pipes > --- > > Key: SLING-7994 > URL: https://issues.apache.org/jira/browse/SLING-7994 > Project: Sling > Issue Type: Improvement > Components: Extensions, pipes >Affects Versions: pipes 3.0.2 >Reporter: Nicolas Peltier >Priority: Major > Fix For: pipes 3.1.0 > > > add a skipExecution flag to pipe, and the superpipe's behaviour to ignore > execution of a subpipe with that flag set -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-8115) pipes log should mention execution time
[
https://issues.apache.org/jira/browse/SLING-8115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Peltier updated SLING-8115:
---
Fix Version/s: pipes 3.1.0
> pipes log should mention execution time
> ---
>
> Key: SLING-8115
> URL: https://issues.apache.org/jira/browse/SLING-8115
> Project: Sling
> Issue Type: Improvement
> Components: pipes
>Affects Versions: pipes 3.0.2
>Reporter: Nicolas Peltier
>Priority: Trivial
> Fix For: pipes 3.1.0
>
>
> while we can make an operation between start and end, it does not cost much
> and would be handy to have total execution time in the last line,
> so something like {{done executing in 12931s}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SLING-8114) Allow to do polling of code failing on asserts
Thierry Ygé created SLING-8114:
--
Summary: Allow to do polling of code failing on asserts
Key: SLING-8114
URL: https://issues.apache.org/jira/browse/SLING-8114
Project: Sling
Issue Type: Improvement
Components: Apache Sling Testing Clients
Affects Versions: Apache Sling Testing Clients 1.2.0
Reporter: Thierry Ygé
Currently if you polling check uses assertions , it will not be retried, this
is due to this line
[https://github.com/apache/sling-org-apache-sling-testing-clients/blob/master/src/main/java/org/apache/sling/testing/clients/util/poller/Polling.java#L118]
Which is only catching Exceptions while failing Assertions are an error kind
(AssertionError).
It would be nice to handle it so that code wouldn't have to "transform" it to
exception.
To reproduce simply use assertion in your polling check and let it fail if a
counter is lower than a value. make the polling retries so that at the next
retry counter it should pass.
{quote}int count = 0;
new Polling(() -> {
count++;
Assert.assertTrue(count == 2);
return true;
}).poll(2000, 500);
{quote}
Observation: it exist the poll directly as the assert fail already.
Expected: It should have polled until the check pass here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-8112) Feature IO ArtifactManagerConfig does not properly access local repository on Windows
[
https://issues.apache.org/jira/browse/SLING-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated SLING-8112:
--
Summary: Feature IO ArtifactManagerConfig does not properly access local
repository on Windows (was: Feature launcher does not properly access local
repository on Windows)
> Feature IO ArtifactManagerConfig does not properly access local repository on
> Windows
> -
>
> Key: SLING-8112
> URL: https://issues.apache.org/jira/browse/SLING-8112
> Project: Sling
> Issue Type: Bug
> Components: Feature Model
>Reporter: Robert Munteanu
>Priority: Critical
> Fix For: Feature Model IO 0.2.2
>
>
> I've received reports that on Windows the local repository is not taken into
> account, and it would see that FTP(??) access is attempted
> {noformat}Artifact Repositories: [file://C:\Users\XXX/.m2/repository,
> https://repo.maven.apache.org/maven2,
> https://repository.apache.org/content/groups/snapshots]
> [INFO] Assembling provisioning model...
> [INFO] Artifact not found in one repository
> java.net.ConnectException: Connection timed out: connect
> at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method)
> at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source)
> at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)
> at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source)
> at java.net.AbstractPlainSocketImpl.connect(Unknown Source)
> at java.net.PlainSocketImpl.connect(Unknown Source)
> at java.net.Socket.connect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.doConnect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.tryConnect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.connect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.connect(Unknown Source)
> at sun.net.www.protocol.ftp.FtpURLConnection.connect(Unknown Source)
> at
> org.apache.sling.feature.io.file.ArtifactManager$DefaultArtifactHandler.getArtifact(ArtifactManager.java:334)
> at
> org.apache.sling.feature.io.file.ArtifactManager.getArtifactHandler(ArtifactManager.java:188)
> at
> org.apache.sling.feature.launcher.impl.FeatureProcessor.createApplication(FeatureProcessor.java:99)
> at org.apache.sling.feature.launcher.impl.Main.assemble(Main.java:315)
> at org.apache.sling.feature.launcher.impl.Main.main(Main.java:222){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-8112) Feature IO ArtifactManagerConfig does not properly access local repository on Windows
[
https://issues.apache.org/jira/browse/SLING-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689473#comment-16689473
]
Karl Pauls commented on SLING-8112:
---
[~rombert], I committed something to feature io which hopefully fixes this
issue. Are you able to test this with the latest laucher snapshot?
> Feature IO ArtifactManagerConfig does not properly access local repository on
> Windows
> -
>
> Key: SLING-8112
> URL: https://issues.apache.org/jira/browse/SLING-8112
> Project: Sling
> Issue Type: Bug
> Components: Feature Model
>Reporter: Robert Munteanu
>Assignee: Karl Pauls
>Priority: Critical
> Fix For: Feature Model IO 0.2.2
>
>
> I've received reports that on Windows the local repository is not taken into
> account, and it would see that FTP(??) access is attempted
> {noformat}Artifact Repositories: [file://C:\Users\XXX/.m2/repository,
> https://repo.maven.apache.org/maven2,
> https://repository.apache.org/content/groups/snapshots]
> [INFO] Assembling provisioning model...
> [INFO] Artifact not found in one repository
> java.net.ConnectException: Connection timed out: connect
> at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method)
> at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source)
> at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)
> at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source)
> at java.net.AbstractPlainSocketImpl.connect(Unknown Source)
> at java.net.PlainSocketImpl.connect(Unknown Source)
> at java.net.Socket.connect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.doConnect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.tryConnect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.connect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.connect(Unknown Source)
> at sun.net.www.protocol.ftp.FtpURLConnection.connect(Unknown Source)
> at
> org.apache.sling.feature.io.file.ArtifactManager$DefaultArtifactHandler.getArtifact(ArtifactManager.java:334)
> at
> org.apache.sling.feature.io.file.ArtifactManager.getArtifactHandler(ArtifactManager.java:188)
> at
> org.apache.sling.feature.launcher.impl.FeatureProcessor.createApplication(FeatureProcessor.java:99)
> at org.apache.sling.feature.launcher.impl.Main.assemble(Main.java:315)
> at org.apache.sling.feature.launcher.impl.Main.main(Main.java:222){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-8114) Allow to do polling of code failing on asserts
[
https://issues.apache.org/jira/browse/SLING-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thierry Ygé updated SLING-8114:
---
Description:
Currently if you polling check uses assertions , it will not be retried, this
is due to this line
[https://github.com/apache/sling-org-apache-sling-testing-clients/blob/master/src/main/java/org/apache/sling/testing/clients/util/poller/Polling.java#L118]
Which is only catching Exceptions while failing Assertions are an error kind
(AssertionError).
It would be nice to handle it so that code wouldn't have to "transform" it to
exception.
To reproduce simply use assertion in your polling check and let it fail if a
counter is lower than a value. make the polling retries so that at the next
retry counter it should pass.
{quote}int count = 0;
new Polling(() -> { count++; Assert.assertTrue(count == 2); return true;
}
).poll(2000, 500);
{quote}
Observation: it exist the poll directly as the assert fail already.
Expected: It should have polled until the check pass here.
was:
Currently if you polling check uses assertions , it will not be retried, this
is due to this line
[https://github.com/apache/sling-org-apache-sling-testing-clients/blob/master/src/main/java/org/apache/sling/testing/clients/util/poller/Polling.java#L118]
Which is only catching Exceptions while failing Assertions are an error kind
(AssertionError).
It would be nice to handle it so that code wouldn't have to "transform" it to
exception.
To reproduce simply use assertion in your polling check and let it fail if a
counter is lower than a value. make the polling retries so that at the next
retry counter it should pass.
{quote}int count = 0;
new Polling(() -> {
count++;
Assert.assertTrue(count == 2);
return true;
}).poll(2000, 500);
{quote}
Observation: it exist the poll directly as the assert fail already.
Expected: It should have polled until the check pass here.
> Allow to do polling of code failing on asserts
> --
>
> Key: SLING-8114
> URL: https://issues.apache.org/jira/browse/SLING-8114
> Project: Sling
> Issue Type: Improvement
> Components: Apache Sling Testing Clients
>Affects Versions: Apache Sling Testing Clients 1.2.0
>Reporter: Thierry Ygé
>Priority: Major
>
> Currently if you polling check uses assertions , it will not be retried, this
> is due to this line
> [https://github.com/apache/sling-org-apache-sling-testing-clients/blob/master/src/main/java/org/apache/sling/testing/clients/util/poller/Polling.java#L118]
> Which is only catching Exceptions while failing Assertions are an error kind
> (AssertionError).
> It would be nice to handle it so that code wouldn't have to "transform" it to
> exception.
> To reproduce simply use assertion in your polling check and let it fail if a
> counter is lower than a value. make the polling retries so that at the next
> retry counter it should pass.
>
> {quote}int count = 0;
> new Polling(() -> { count++; Assert.assertTrue(count == 2); return true;
> }
> ).poll(2000, 500);
> {quote}
> Observation: it exist the poll directly as the assert fail already.
> Expected: It should have polled until the check pass here.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (SLING-8112) Feature IO ArtifactManagerConfig does not properly access local repository on Windows
[
https://issues.apache.org/jira/browse/SLING-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls reassigned SLING-8112:
-
Assignee: Karl Pauls
> Feature IO ArtifactManagerConfig does not properly access local repository on
> Windows
> -
>
> Key: SLING-8112
> URL: https://issues.apache.org/jira/browse/SLING-8112
> Project: Sling
> Issue Type: Bug
> Components: Feature Model
>Reporter: Robert Munteanu
>Assignee: Karl Pauls
>Priority: Critical
> Fix For: Feature Model IO 0.2.2
>
>
> I've received reports that on Windows the local repository is not taken into
> account, and it would see that FTP(??) access is attempted
> {noformat}Artifact Repositories: [file://C:\Users\XXX/.m2/repository,
> https://repo.maven.apache.org/maven2,
> https://repository.apache.org/content/groups/snapshots]
> [INFO] Assembling provisioning model...
> [INFO] Artifact not found in one repository
> java.net.ConnectException: Connection timed out: connect
> at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method)
> at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source)
> at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)
> at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source)
> at java.net.AbstractPlainSocketImpl.connect(Unknown Source)
> at java.net.PlainSocketImpl.connect(Unknown Source)
> at java.net.Socket.connect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.doConnect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.tryConnect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.connect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.connect(Unknown Source)
> at sun.net.www.protocol.ftp.FtpURLConnection.connect(Unknown Source)
> at
> org.apache.sling.feature.io.file.ArtifactManager$DefaultArtifactHandler.getArtifact(ArtifactManager.java:334)
> at
> org.apache.sling.feature.io.file.ArtifactManager.getArtifactHandler(ArtifactManager.java:188)
> at
> org.apache.sling.feature.launcher.impl.FeatureProcessor.createApplication(FeatureProcessor.java:99)
> at org.apache.sling.feature.launcher.impl.Main.assemble(Main.java:315)
> at org.apache.sling.feature.launcher.impl.Main.main(Main.java:222){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-8112) Feature launcher does not properly access local repository on Windows
[
https://issues.apache.org/jira/browse/SLING-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated SLING-8112:
--
Fix Version/s: (was: Feature Model Launcher 0.2.2)
Feature Model IO 0.2.2
> Feature launcher does not properly access local repository on Windows
> -
>
> Key: SLING-8112
> URL: https://issues.apache.org/jira/browse/SLING-8112
> Project: Sling
> Issue Type: Bug
> Components: Feature Model
>Reporter: Robert Munteanu
>Priority: Critical
> Fix For: Feature Model IO 0.2.2
>
>
> I've received reports that on Windows the local repository is not taken into
> account, and it would see that FTP(??) access is attempted
> {noformat}Artifact Repositories: [file://C:\Users\XXX/.m2/repository,
> https://repo.maven.apache.org/maven2,
> https://repository.apache.org/content/groups/snapshots]
> [INFO] Assembling provisioning model...
> [INFO] Artifact not found in one repository
> java.net.ConnectException: Connection timed out: connect
> at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method)
> at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source)
> at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)
> at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source)
> at java.net.AbstractPlainSocketImpl.connect(Unknown Source)
> at java.net.PlainSocketImpl.connect(Unknown Source)
> at java.net.Socket.connect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.doConnect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.tryConnect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.connect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.connect(Unknown Source)
> at sun.net.www.protocol.ftp.FtpURLConnection.connect(Unknown Source)
> at
> org.apache.sling.feature.io.file.ArtifactManager$DefaultArtifactHandler.getArtifact(ArtifactManager.java:334)
> at
> org.apache.sling.feature.io.file.ArtifactManager.getArtifactHandler(ArtifactManager.java:188)
> at
> org.apache.sling.feature.launcher.impl.FeatureProcessor.createApplication(FeatureProcessor.java:99)
> at org.apache.sling.feature.launcher.impl.Main.assemble(Main.java:315)
> at org.apache.sling.feature.launcher.impl.Main.main(Main.java:222){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-8113) Set statusfilepath of package-init to registryHome via content-extension
[ https://issues.apache.org/jira/browse/SLING-8113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689435#comment-16689435 ] ASF GitHub Bot commented on SLING-8113: --- DominikSuess opened a new pull request #10: SLING-8113 - defining file in registryhome to capture executionplan s… URL: https://github.com/apache/sling-org-apache-sling-feature-extension-content/pull/10 …tatus. 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 > Set statusfilepath of package-init to registryHome via content-extension > > > Key: SLING-8113 > URL: https://issues.apache.org/jira/browse/SLING-8113 > Project: Sling > Issue Type: Improvement >Reporter: Dominik Süß >Assignee: Dominik Süß >Priority: Major > > The statusfile of packageinit by default is persisted in the bundledata > repository to be by default agnostic of the filesystem structures. Anyhow in > case of usage along with content-extension the registry home is already > declared and is in contrast to the framework not supposed to be rebuilt and > therfore a more reliable location to store. As the content-extension already > generates the configuration for this service this is an easy addition to > persist the statusfile in the packageregistries home directory. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] DominikSuess opened a new pull request #10: SLING-8113 - defining file in registryhome to capture executionplan s…
DominikSuess opened a new pull request #10: SLING-8113 - defining file in registryhome to capture executionplan s… URL: https://github.com/apache/sling-org-apache-sling-feature-extension-content/pull/10 …tatus. 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] [Created] (SLING-8113) Set statusfilepath of package-init to registryHome via content-extension
Dominik Süß created SLING-8113: -- Summary: Set statusfilepath of package-init to registryHome via content-extension Key: SLING-8113 URL: https://issues.apache.org/jira/browse/SLING-8113 Project: Sling Issue Type: Improvement Reporter: Dominik Süß Assignee: Dominik Süß The statusfile of packageinit by default is persisted in the bundledata repository to be by default agnostic of the filesystem structures. Anyhow in case of usage along with content-extension the registry home is already declared and is in contrast to the framework not supposed to be rebuilt and therfore a more reliable location to store. As the content-extension already generates the configuration for this service this is an easy addition to persist the statusfile in the packageregistries home directory. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-8112) Feature launcher does not properly access local repository on Windows
[
https://issues.apache.org/jira/browse/SLING-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-8112:
---
Priority: Critical (was: Major)
> Feature launcher does not properly access local repository on Windows
> -
>
> Key: SLING-8112
> URL: https://issues.apache.org/jira/browse/SLING-8112
> Project: Sling
> Issue Type: Bug
> Components: Feature Model
>Reporter: Robert Munteanu
>Priority: Critical
> Fix For: Feature Model Launcher 0.2.2
>
>
> I've received reports that on Windows the local repository is not taken into
> account, and it would see that FTP(??) access is attempted
> {noformat}Artifact Repositories: [file://C:\Users\XXX/.m2/repository,
> https://repo.maven.apache.org/maven2,
> https://repository.apache.org/content/groups/snapshots]
> [INFO] Assembling provisioning model...
> [INFO] Artifact not found in one repository
> java.net.ConnectException: Connection timed out: connect
> at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method)
> at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source)
> at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)
> at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source)
> at java.net.AbstractPlainSocketImpl.connect(Unknown Source)
> at java.net.PlainSocketImpl.connect(Unknown Source)
> at java.net.Socket.connect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.doConnect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.tryConnect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.connect(Unknown Source)
> at sun.net.ftp.impl.FtpClient.connect(Unknown Source)
> at sun.net.www.protocol.ftp.FtpURLConnection.connect(Unknown Source)
> at
> org.apache.sling.feature.io.file.ArtifactManager$DefaultArtifactHandler.getArtifact(ArtifactManager.java:334)
> at
> org.apache.sling.feature.io.file.ArtifactManager.getArtifactHandler(ArtifactManager.java:188)
> at
> org.apache.sling.feature.launcher.impl.FeatureProcessor.createApplication(FeatureProcessor.java:99)
> at org.apache.sling.feature.launcher.impl.Main.assemble(Main.java:315)
> at org.apache.sling.feature.launcher.impl.Main.main(Main.java:222){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SLING-8112) Feature launcher does not properly access local repository on Windows
Robert Munteanu created SLING-8112:
--
Summary: Feature launcher does not properly access local
repository on Windows
Key: SLING-8112
URL: https://issues.apache.org/jira/browse/SLING-8112
Project: Sling
Issue Type: Bug
Components: Feature Model
Reporter: Robert Munteanu
Fix For: Feature Model Launcher 0.2.2
I've received reports that on Windows the local repository is not taken into
account, and it would see that FTP(??) access is attempted
{noformat}Artifact Repositories: [file://C:\Users\XXX/.m2/repository,
https://repo.maven.apache.org/maven2,
https://repository.apache.org/content/groups/snapshots]
[INFO] Assembling provisioning model...
[INFO] Artifact not found in one repository
java.net.ConnectException: Connection timed out: connect
at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method)
at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source)
at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)
at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source)
at java.net.AbstractPlainSocketImpl.connect(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at sun.net.ftp.impl.FtpClient.doConnect(Unknown Source)
at sun.net.ftp.impl.FtpClient.tryConnect(Unknown Source)
at sun.net.ftp.impl.FtpClient.connect(Unknown Source)
at sun.net.ftp.impl.FtpClient.connect(Unknown Source)
at sun.net.www.protocol.ftp.FtpURLConnection.connect(Unknown Source)
at
org.apache.sling.feature.io.file.ArtifactManager$DefaultArtifactHandler.getArtifact(ArtifactManager.java:334)
at
org.apache.sling.feature.io.file.ArtifactManager.getArtifactHandler(ArtifactManager.java:188)
at
org.apache.sling.feature.launcher.impl.FeatureProcessor.createApplication(FeatureProcessor.java:99)
at org.apache.sling.feature.launcher.impl.Main.assemble(Main.java:315)
at org.apache.sling.feature.launcher.impl.Main.main(Main.java:222){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [VOTE] Release Apache Sling Testing JCR Mock 1.4.2, OSGi Mock 2.4.4
+1 > On 15 Nov 2018, at 16:00, Stefan Seifert wrote: > > 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] [Created] (SLING-8111) API to enable tracer configuration
Nitin Nizhawan created SLING-8111: - Summary: API to enable tracer configuration Key: SLING-8111 URL: https://issues.apache.org/jira/browse/SLING-8111 Project: Sling Issue Type: Improvement Components: Tooling Reporter: Nitin Nizhawan Sling Tracers allows enabling loggers using request parameters. But these configs can only be specified for request thread. In cases where a thread is not associated with request it cannot be done currently and requires addition of new API -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-8111) API to enable tracer configuration
[ https://issues.apache.org/jira/browse/SLING-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Nizhawan updated SLING-8111: -- Description: Sling Tracers allows enabling loggers using request parameters. But these configs can only be specified for request thread. In cases where a thread is not associated with request it cannot be done currently and requires addition of new API CC: [~chetanm] was: Sling Tracers allows enabling loggers using request parameters. But these configs can only be specified for request thread. In cases where a thread is not associated with request it cannot be done currently and requires addition of new API > API to enable tracer configuration > --- > > Key: SLING-8111 > URL: https://issues.apache.org/jira/browse/SLING-8111 > Project: Sling > Issue Type: Improvement > Components: Tooling >Affects Versions: Log Tracer 1.0.8 >Reporter: Nitin Nizhawan >Priority: Major > > Sling Tracers allows enabling loggers using request parameters. But these > configs can only be specified for request thread. In cases where a thread is > not associated with request it cannot be done currently and requires addition > of new API > > CC: [~chetanm] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-8111) API to enable tracer configuration
[ https://issues.apache.org/jira/browse/SLING-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Nizhawan updated SLING-8111: -- Affects Version/s: Log Tracer 1.0.8 > API to enable tracer configuration > --- > > Key: SLING-8111 > URL: https://issues.apache.org/jira/browse/SLING-8111 > Project: Sling > Issue Type: Improvement > Components: Tooling >Affects Versions: Log Tracer 1.0.8 >Reporter: Nitin Nizhawan >Priority: Major > > Sling Tracers allows enabling loggers using request parameters. But these > configs can only be specified for request thread. In cases where a thread is > not associated with request it cannot be done currently and requires addition > of new API > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[ https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689281#comment-16689281 ] ASF GitHub Bot commented on SLING-8104: --- bosschaert commented on issue #8: SLING-8104 Avoid magic when merging features URL: https://github.com/apache/sling-org-apache-sling-feature/pull/8#issuecomment-439357538 Hi @cziegeler thanks for reviewing. > The other methods in the BuilderContext should be renamed from *Overwrites to *Overrides as well Yes, I'm planning to do this separately. Good point on the includes - I'll update this pull request with an implementation along the lines of what you have suggested. 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 > Avoid magic when merging features > - > > Key: SLING-8104 > URL: https://issues.apache.org/jira/browse/SLING-8104 > Project: Sling > Issue Type: Improvement > Components: Feature Model >Reporter: Carsten Ziegeler >Assignee: David Bosschaert >Priority: Blocker > Fix For: slingfeature-maven-plugin 1.0.0, Feature Model 0.2.2 > > > Currently when features are merged a simple algorithm is applied which just > picks the highest version based on the artifact version. However this version > might not have no meaning at all and might not really reflect what has > changed inside the bundle. > Especially when there is a major version change, this approach seems to be > clearly wrong > But in the end, picking a single version is magic. > While the problem could probably be solved by using something like a resolver > and figure out if just one version is enough or if both versions are needed, > without a resolver there is no way to figure this out. > Therefore we should provide a similar way as we do for variables at the > moment: if there is a clash the caller needs to provide context on what to > choose. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] bosschaert commented on issue #8: SLING-8104 Avoid magic when merging features
bosschaert commented on issue #8: SLING-8104 Avoid magic when merging features URL: https://github.com/apache/sling-org-apache-sling-feature/pull/8#issuecomment-439357538 Hi @cziegeler thanks for reviewing. > The other methods in the BuilderContext should be renamed from *Overwrites to *Overrides as well Yes, I'm planning to do this separately. Good point on the includes - I'll update this pull request with an implementation along the lines of what you have suggested. 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
Re: [VOTE] Release Apache Sling Testing JCR Mock 1.4.2, OSGi Mock 2.4.4
On Thu, 2018-11-15 at 15:00 +, Stefan Seifert wrote: > Please vote to approve this release: +1 Robert signature.asc Description: This is a digitally signed message part
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[ https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689160#comment-16689160 ] ASF GitHub Bot commented on SLING-8104: --- cziegeler edited a comment on issue #8: SLING-8104 Avoid magic when merging features URL: https://github.com/apache/sling-org-apache-sling-feature/pull/8#issuecomment-439295972 This looks basically good to me, two comments: The other methods in the BuilderContext should be renamed from *Overwrites to *Overrides as well The new mechanism is now also used to process an include; however I think an include should be processable without providing additional information. So far, the latest artifact won, meaning that the one from the feature that has the include wins, which seems logical. On the other hand, this prevents the use case of having both versions. We already have the "remove" section in an include, we could add a "replace" section there as well which then means: Let's assume feature A includes feature I. If A lists a bundle in the replace section, this bundle version will win (== LATEST) If A lists a bundle in the bundles section, both versions will be included (== ALL) The decision for a HIGHEST is done by the feature author. Or we don't have a replace section which then requires to remove a bundle if A wants to provide a different version: If A removes the bundle inherited from I and adds a new one (== LATEST) If A lists a bundle in the bundles section, both versions will be included (==ALL) The first option makes it easier to change the version of a bundle, but introduces a new concept just for this use case. 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 > Avoid magic when merging features > - > > Key: SLING-8104 > URL: https://issues.apache.org/jira/browse/SLING-8104 > Project: Sling > Issue Type: Improvement > Components: Feature Model >Reporter: Carsten Ziegeler >Assignee: David Bosschaert >Priority: Blocker > Fix For: slingfeature-maven-plugin 1.0.0, Feature Model 0.2.2 > > > Currently when features are merged a simple algorithm is applied which just > picks the highest version based on the artifact version. However this version > might not have no meaning at all and might not really reflect what has > changed inside the bundle. > Especially when there is a major version change, this approach seems to be > clearly wrong > But in the end, picking a single version is magic. > While the problem could probably be solved by using something like a resolver > and figure out if just one version is enough or if both versions are needed, > without a resolver there is no way to figure this out. > Therefore we should provide a similar way as we do for variables at the > moment: if there is a clash the caller needs to provide context on what to > choose. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] cziegeler edited a comment on issue #8: SLING-8104 Avoid magic when merging features
cziegeler edited a comment on issue #8: SLING-8104 Avoid magic when merging features URL: https://github.com/apache/sling-org-apache-sling-feature/pull/8#issuecomment-439295972 This looks basically good to me, two comments: The other methods in the BuilderContext should be renamed from *Overwrites to *Overrides as well The new mechanism is now also used to process an include; however I think an include should be processable without providing additional information. So far, the latest artifact won, meaning that the one from the feature that has the include wins, which seems logical. On the other hand, this prevents the use case of having both versions. We already have the "remove" section in an include, we could add a "replace" section there as well which then means: Let's assume feature A includes feature I. If A lists a bundle in the replace section, this bundle version will win (== LATEST) If A lists a bundle in the bundles section, both versions will be included (== ALL) The decision for a HIGHEST is done by the feature author. Or we don't have a replace section which then requires to remove a bundle if A wants to provide a different version: If A removes the bundle inherited from I and adds a new one (== LATEST) If A lists a bundle in the bundles section, both versions will be included (==ALL) The first option makes it easier to change the version of a bundle, but introduces a new concept just for this use case. 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
