[jira] [Created] (SLING-5247) Update Jackrabbit to 2.11.2
Oliver Lietz created SLING-5247: --- Summary: Update Jackrabbit to 2.11.2 Key: SLING-5247 URL: https://issues.apache.org/jira/browse/SLING-5247 Project: Sling Issue Type: Task Components: JCR, Launchpad Reporter: Oliver Lietz Assignee: Oliver Lietz Fix For: Launchpad Karaf Features 0.2.0, Launchpad Builder 9 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5149) Generate OSGi subsystem intermediary file in slingstart-maven-plugin
[ https://issues.apache.org/jira/browse/SLING-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14986990#comment-14986990 ] Carsten Ziegeler commented on SLING-5149: - Patch lgtm > Generate OSGi subsystem intermediary file in slingstart-maven-plugin > > > Key: SLING-5149 > URL: https://issues.apache.org/jira/browse/SLING-5149 > Project: Sling > Issue Type: New Feature > Components: Maven Plugins and Archetypes >Affects Versions: Slingstart Maven Plugin 1.3.6 >Reporter: David Bosschaert > Fix For: Slingstart Maven Plugin 1.3.8 > > Attachments: SLING-5149.diff > > > Enhance the slingstart-maven-plugin to support OSGi subsystems as modeled via > SLING-5148. The maven plugin should generate an .esa file from the artifacts > defined as an OSGi subsystem in the provisioning model. The resulting .esa > files should be embedded in the generated archive. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5249) Include provisioning model 1.4.2
Carsten Ziegeler created SLING-5249: --- Summary: Include provisioning model 1.4.2 Key: SLING-5249 URL: https://issues.apache.org/jira/browse/SLING-5249 Project: Sling Issue Type: Improvement Components: Maven Plugins and Archetypes Reporter: Carsten Ziegeler Fix For: Slingstart Maven Plugin 1.3.8 We should release and include 1.4.2 of the provisioning model as 1.4.0 contains a nasty bug -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5149) Generate OSGi subsystem intermediary file in slingstart-maven-plugin
[ https://issues.apache.org/jira/browse/SLING-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-5149: Fix Version/s: Slingstart Maven Plugin 1.3.8 > Generate OSGi subsystem intermediary file in slingstart-maven-plugin > > > Key: SLING-5149 > URL: https://issues.apache.org/jira/browse/SLING-5149 > Project: Sling > Issue Type: New Feature > Components: Maven Plugins and Archetypes >Affects Versions: Slingstart Maven Plugin 1.3.6 >Reporter: David Bosschaert > Fix For: Slingstart Maven Plugin 1.3.8 > > Attachments: SLING-5149.diff > > > Enhance the slingstart-maven-plugin to support OSGi subsystems as modeled via > SLING-5148. The maven plugin should generate an .esa file from the artifacts > defined as an OSGi subsystem in the provisioning model. The resulting .esa > files should be embedded in the generated archive. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-5006) Allow to enable the usage of regular JCR users for service resolvers
[
https://issues.apache.org/jira/browse/SLING-5006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marius Petria resolved SLING-5006.
--
Resolution: Fixed
> Allow to enable the usage of regular JCR users for service resolvers
>
>
> Key: SLING-5006
> URL: https://issues.apache.org/jira/browse/SLING-5006
> Project: Sling
> Issue Type: Improvement
> Components: Service User Mapper
>Affects Versions: Service User Mapper 1.2.0, JCR Resource 2.5.6
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Service User Mapper 1.2.2, JCR Resource 2.6.0
>
> Attachments: SLING-5006-serviceusermapper-v01.diff,
> SLING-5006-uservalidator-v01.diff
>
>
> With SLING-3854 a {{ServiceUserValidator}} interface was introduced.
> Basically all OSGi services implementing that interface may decide whether
> certain users can be used as backing user for a call to
> {{ResourceResolverFactory.getServiceResolver(...)}}. The only implementation
> of that in Sling is {{JcrSystemUserValidator}} which only allows to use JCR
> system users.
> The list of all those services is bound in the {{ServiceUserMapperImpl}}
> dynamically.
> If you for example want to use that service to relax the policy being
> introduced with SLING-3854 (to e.g. allow all users as service users) you may
> register your own service just returning {{true}} for all users in the only
> method {{isValid}}. Unfortunately you don't know when your
> {{ServiceUserValidator}} service is bound (due to the dynamic restart
> behaviour of services). Therefore other services cannot rely on the fact that
> your own {{ServiceUserValidator}} is being available at a certain point in
> time and therefore their call to
> {{ResourceResolverFactory.getServiceResolver(...)}} may fail, if they rely on
> a non-System JCR user. Therefore this mechanism is not suitable to disable
> the enforcing of JCR system users.
> Instead I would propose the following:
> # allow to configure the {{JcrSystemUserValidator}} via an OSGi property
> named {{allowOnlySystemUsers}} which by default should be {{true}}.
> # within the method {{JcrSystemUserValidator.isValidUser}} you either allow
> all users or leave the current logic in place (in case
> {{allowOnlySystemUsers}} is {{true}}).
> Only that way it would be possible to reliably allow all users as service
> users which is especially helpful during development of a certain feature
> (although this is probably not a config you would set on a production
> instance).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-5248) Update Oak to 1.3.9
Oliver Lietz created SLING-5248: --- Summary: Update Oak to 1.3.9 Key: SLING-5248 URL: https://issues.apache.org/jira/browse/SLING-5248 Project: Sling Issue Type: Task Components: JCR, Launchpad Reporter: Oliver Lietz Assignee: Oliver Lietz Fix For: Launchpad Karaf Features 0.2.0, JCR Oak Server 1.0.2, Launchpad Builder 9 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5250) [TESTING][JCR MOCK] MockProperty getValues does not comply with JCR 2.0 API
[
https://issues.apache.org/jira/browse/SLING-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Douillet updated SLING-5250:
--
Description:
Hello,
According to JCR 2.0 API, {{javax.jcr.Property.getValues()}} should throw
{{ValueFormatException}} when the underlying property is single-valued :
{code}
/**
* Returns an array of all the values of this property. Used to access
* multi-value properties. The array returned is a copy of the stored
* values, so changes to it are not reflected in internal storage.
*
* @return a Value array.
* @throws ValueFormatException if the property is single-valued.
* @throws RepositoryException if another error occurs.
*/
public Value[] getValues() throws ValueFormatException, RepositoryException;
{code}
However, {{org.apache.sling.testing.mock.jcr.MockProperty}} implements a
different behavior. {{ValueFormatException}} is not thrown but an array
containing a single value is returned instead.
Here a small test case to put in
{{org.apache.sling.testing.mock.jcr.MockPropertyTest}} exhibiting this behavior
:
{code}
@Test(expected=ValueFormatException.class)
public void testSingleValueAsValueArray() throws RepositoryException {
this.node1.setProperty("prop1",
this.session.getValueFactory().createValue("value1"));
Property prop1 = this.node1.getProperty("prop1");
assertFalse(prop1.isMultiple());
assertEquals("value1", prop1.getValues()[0].getString());
}
{code}
was:
Hello,
According to JCR 2.0 API, {{javax.jcr.Property.getValues()}} should throw
{{ValueFormatException}} when the underlying property is single-values :
{code}
/**
* Returns an array of all the values of this property. Used to access
* multi-value properties. The array returned is a copy of the stored
* values, so changes to it are not reflected in internal storage.
*
* @return a Value array.
* @throws ValueFormatException if the property is single-valued.
* @throws RepositoryException if another error occurs.
*/
public Value[] getValues() throws ValueFormatException, RepositoryException;
{code}
However, {{org.apache.sling.testing.mock.jcr.MockProperty}} implements a
different behavior. {{ValueFormatException}} is not thrown but an array
containing a single value is returned instead.
Here a small test case to put in
{{org.apache.sling.testing.mock.jcr.MockPropertyTest}} exhibiting this behavior
:
{code}
@Test(expected=ValueFormatException.class)
public void testSingleValueAsValueArray() throws RepositoryException {
this.node1.setProperty("prop1",
this.session.getValueFactory().createValue("value1"));
Property prop1 = this.node1.getProperty("prop1");
assertFalse(prop1.isMultiple());
assertEquals("value1", prop1.getValues()[0].getString());
}
{code}
> [TESTING][JCR MOCK] MockProperty getValues does not comply with JCR 2.0 API
> ---
>
> Key: SLING-5250
> URL: https://issues.apache.org/jira/browse/SLING-5250
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Affects Versions: Testing JCR Mock 1.1.10
>Reporter: Guillaume Douillet
>
> Hello,
> According to JCR 2.0 API, {{javax.jcr.Property.getValues()}} should throw
> {{ValueFormatException}} when the underlying property is single-valued :
> {code}
> /**
> * Returns an array of all the values of this property. Used to access
> * multi-value properties. The array returned is a copy of the stored
> * values, so changes to it are not reflected in internal storage.
> *
> * @return a Value array.
> * @throws ValueFormatException if the property is single-valued.
> * @throws RepositoryException if another error occurs.
> */
> public Value[] getValues() throws ValueFormatException,
> RepositoryException;
> {code}
> However, {{org.apache.sling.testing.mock.jcr.MockProperty}} implements a
> different behavior. {{ValueFormatException}} is not thrown but an array
> containing a single value is returned instead.
> Here a small test case to put in
> {{org.apache.sling.testing.mock.jcr.MockPropertyTest}} exhibiting this
> behavior :
> {code}
> @Test(expected=ValueFormatException.class)
> public void testSingleValueAsValueArray() throws RepositoryException {
> this.node1.setProperty("prop1",
> this.session.getValueFactory().createValue("value1"));
> Property prop1 = this.node1.getProperty("prop1");
> assertFalse(prop1.isMultiple());
> assertEquals("value1", prop1.getValues()[0].getString());
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5250) [TESTING][JCR MOCK] MockProperty getValues does not comply with JCR 2.0 API
[
https://issues.apache.org/jira/browse/SLING-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Douillet updated SLING-5250:
--
Description:
Hello,
According to JCR 2.0 API, {{javax.jcr.Property.getValues()}} should throw
{{ValueFormatException}} when the underlying property is single-valued :
{code}
/**
* Returns an array of all the values of this property. Used to access
* multi-value properties. The array returned is a copy of the stored
* values, so changes to it are not reflected in internal storage.
*
* @return a Value array.
* @throws ValueFormatException if the property is single-valued.
* @throws RepositoryException if another error occurs.
*/
public Value[] getValues() throws ValueFormatException, RepositoryException;
{code}
However, {{org.apache.sling.testing.mock.jcr.MockProperty}} implements a
different behavior. {{ValueFormatException}} is not thrown but an array
containing a single value is returned instead.
Here a small test case exhibiting this behavior (to put in
{{org.apache.sling.testing.mock.jcr.MockPropertyTest}}) :
{code}
@Test(expected=ValueFormatException.class)
public void testSingleValueAsValueArray() throws RepositoryException {
this.node1.setProperty("prop1",
this.session.getValueFactory().createValue("value1"));
Property prop1 = this.node1.getProperty("prop1");
assertFalse(prop1.isMultiple());
assertEquals("value1", prop1.getValues()[0].getString());
}
{code}
was:
Hello,
According to JCR 2.0 API, {{javax.jcr.Property.getValues()}} should throw
{{ValueFormatException}} when the underlying property is single-valued :
{code}
/**
* Returns an array of all the values of this property. Used to access
* multi-value properties. The array returned is a copy of the stored
* values, so changes to it are not reflected in internal storage.
*
* @return a Value array.
* @throws ValueFormatException if the property is single-valued.
* @throws RepositoryException if another error occurs.
*/
public Value[] getValues() throws ValueFormatException, RepositoryException;
{code}
However, {{org.apache.sling.testing.mock.jcr.MockProperty}} implements a
different behavior. {{ValueFormatException}} is not thrown but an array
containing a single value is returned instead.
Here a small test case to put in
{{org.apache.sling.testing.mock.jcr.MockPropertyTest}} exhibiting this behavior
:
{code}
@Test(expected=ValueFormatException.class)
public void testSingleValueAsValueArray() throws RepositoryException {
this.node1.setProperty("prop1",
this.session.getValueFactory().createValue("value1"));
Property prop1 = this.node1.getProperty("prop1");
assertFalse(prop1.isMultiple());
assertEquals("value1", prop1.getValues()[0].getString());
}
{code}
> [TESTING][JCR MOCK] MockProperty getValues does not comply with JCR 2.0 API
> ---
>
> Key: SLING-5250
> URL: https://issues.apache.org/jira/browse/SLING-5250
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Affects Versions: Testing JCR Mock 1.1.10
>Reporter: Guillaume Douillet
>
> Hello,
> According to JCR 2.0 API, {{javax.jcr.Property.getValues()}} should throw
> {{ValueFormatException}} when the underlying property is single-valued :
> {code}
> /**
> * Returns an array of all the values of this property. Used to access
> * multi-value properties. The array returned is a copy of the stored
> * values, so changes to it are not reflected in internal storage.
> *
> * @return a Value array.
> * @throws ValueFormatException if the property is single-valued.
> * @throws RepositoryException if another error occurs.
> */
> public Value[] getValues() throws ValueFormatException,
> RepositoryException;
> {code}
> However, {{org.apache.sling.testing.mock.jcr.MockProperty}} implements a
> different behavior. {{ValueFormatException}} is not thrown but an array
> containing a single value is returned instead.
> Here a small test case exhibiting this behavior (to put in
> {{org.apache.sling.testing.mock.jcr.MockPropertyTest}}) :
> {code}
> @Test(expected=ValueFormatException.class)
> public void testSingleValueAsValueArray() throws RepositoryException {
> this.node1.setProperty("prop1",
> this.session.getValueFactory().createValue("value1"));
> Property prop1 = this.node1.getProperty("prop1");
> assertFalse(prop1.isMultiple());
> assertEquals("value1", prop1.getValues()[0].getString());
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5250) [TESTING][JCR MOCK] MockProperty getValues does not comply with JCR 2.0 API
[
https://issues.apache.org/jira/browse/SLING-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Douillet updated SLING-5250:
--
Description:
Hello,
According to JCR 2.0 API, {{javax.jcr.Property.getValues()}} should throw
{{ValueFormatException}} when the underlying property is single-values :
{code}
/**
* Returns an array of all the values of this property. Used to access
* multi-value properties. The array returned is a copy of the stored
* values, so changes to it are not reflected in internal storage.
*
* @return a Value array.
* @throws ValueFormatException if the property is single-valued.
* @throws RepositoryException if another error occurs.
*/
public Value[] getValues() throws ValueFormatException, RepositoryException;
{code}
However, {{org.apache.sling.testing.mock.jcr.MockProperty}} implements a
different behavior. {{ValueFormatException}} is not thrown but an array
containing a single value is returned instead.
Here a small test case to put in
{{org.apache.sling.testing.mock.jcr.MockPropertyTest}} exhibiting this behavior
:
{code}
@Test(expected=ValueFormatException.class)
public void testSingleValueAsValueArray() throws RepositoryException {
this.node1.setProperty("prop1",
this.session.getValueFactory().createValue("value1"));
Property prop1 = this.node1.getProperty("prop1");
assertFalse(prop1.isMultiple());
assertEquals("value1", prop1.getValues()[0].getString());
}
{code}
was:
Hello,
According to JCR 2.0 API, {{javax.jcr.Property.getValues()}} should throw
ValueFormatException when the underlying property is single-values :
{code}
/**
* Returns an array of all the values of this property. Used to access
* multi-value properties. The array returned is a copy of the stored
* values, so changes to it are not reflected in internal storage.
*
* @return a Value array.
* @throws ValueFormatException if the property is single-valued.
* @throws RepositoryException if another error occurs.
*/
public Value[] getValues() throws ValueFormatException, RepositoryException;
{code}
However, {{org.apache.sling.testing.mock.jcr.MockProperty}} implements a
different behavior. {{ValueFormatException}} is not thrown but an array
containing a single value is returned instead.
Here a small test case to put in
{{org.apache.sling.testing.mock.jcr.MockPropertyTest}} exhibiting this behavior
:
{code}
@Test(expected=ValueFormatException.class)
public void testSingleValueAsValueArray() throws RepositoryException {
this.node1.setProperty("prop1",
this.session.getValueFactory().createValue("value1"));
Property prop1 = this.node1.getProperty("prop1");
assertFalse(prop1.isMultiple());
assertEquals("value1", prop1.getValues()[0].getString());
}
{code}
> [TESTING][JCR MOCK] MockProperty getValues does not comply with JCR 2.0 API
> ---
>
> Key: SLING-5250
> URL: https://issues.apache.org/jira/browse/SLING-5250
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Affects Versions: Testing JCR Mock 1.1.10
>Reporter: Guillaume Douillet
>
> Hello,
> According to JCR 2.0 API, {{javax.jcr.Property.getValues()}} should throw
> {{ValueFormatException}} when the underlying property is single-values :
> {code}
> /**
> * Returns an array of all the values of this property. Used to access
> * multi-value properties. The array returned is a copy of the stored
> * values, so changes to it are not reflected in internal storage.
> *
> * @return a Value array.
> * @throws ValueFormatException if the property is single-valued.
> * @throws RepositoryException if another error occurs.
> */
> public Value[] getValues() throws ValueFormatException,
> RepositoryException;
> {code}
> However, {{org.apache.sling.testing.mock.jcr.MockProperty}} implements a
> different behavior. {{ValueFormatException}} is not thrown but an array
> containing a single value is returned instead.
> Here a small test case to put in
> {{org.apache.sling.testing.mock.jcr.MockPropertyTest}} exhibiting this
> behavior :
> {code}
> @Test(expected=ValueFormatException.class)
> public void testSingleValueAsValueArray() throws RepositoryException {
> this.node1.setProperty("prop1",
> this.session.getValueFactory().createValue("value1"));
> Property prop1 = this.node1.getProperty("prop1");
> assertFalse(prop1.isMultiple());
> assertEquals("value1", prop1.getValues()[0].getString());
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-5250) [TESTING][JCR MOCK] MockProperty getValues does not comply with JCR 2.0 API
Guillaume Douillet created SLING-5250:
-
Summary: [TESTING][JCR MOCK] MockProperty getValues does not
comply with JCR 2.0 API
Key: SLING-5250
URL: https://issues.apache.org/jira/browse/SLING-5250
Project: Sling
Issue Type: Bug
Components: Testing
Affects Versions: Testing JCR Mock 1.1.10
Reporter: Guillaume Douillet
Hello,
According to JCR 2.0 API, {{javax.jcr.Property.getValues()}} should throw
ValueFormatException when the underlying property is single-values :
{code}
/**
* Returns an array of all the values of this property. Used to access
* multi-value properties. The array returned is a copy of the stored
* values, so changes to it are not reflected in internal storage.
*
* @return a Value array.
* @throws ValueFormatException if the property is single-valued.
* @throws RepositoryException if another error occurs.
*/
public Value[] getValues() throws ValueFormatException, RepositoryException;
{code}
However, {{org.apache.sling.testing.mock.jcr.MockProperty}} implements a
different behavior. {{ValueFormatException}} is not thrown but an array
containing a single value is returned instead.
Here a small test case to put in
{{org.apache.sling.testing.mock.jcr.MockPropertyTest}} exhibiting this behavior
:
{code}
@Test(expected=ValueFormatException.class)
public void testSingleValueAsValueArray() throws RepositoryException {
this.node1.setProperty("prop1",
this.session.getValueFactory().createValue("value1"));
Property prop1 = this.node1.getProperty("prop1");
assertFalse(prop1.isMultiple());
assertEquals("value1", prop1.getValues()[0].getString());
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-5251) discovery.impl should use SyncTokenService (configurable)
Stefan Egli created SLING-5251: -- Summary: discovery.impl should use SyncTokenService (configurable) Key: SLING-5251 URL: https://issues.apache.org/jira/browse/SLING-5251 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Discovery Impl 1.2.0 Reporter: Stefan Egli Assignee: Stefan Egli Fix For: Discovery Impl 1.2.2 The SyncTokenService introduced with discovery.commons allows discovery implementors to add additional QoS to a TOPOLOGY_CHANGED event by waiting for each instance to store a 'sync token' (eg cluster *view* id, not cluster id) into the repository. Namely the following: * upon detecting a topology change happening, each instance sends out TOPOLOGY_CHANGING to its listeners * *after* that is done, it stores a syncToken to a well-known place into the repository * thus when a particular instance sees all syncTokens by the peers, it knows that all listeners have now gotten the TOPOLOGY_CHANGING event - and that provides a strong synchronization guarantee. This mechanism is already in-use by default in discovery.oak (which additionally also ensures no instance has any backlog with the repository - which it can do as it requires oak and oak provides this info in the discovery-lite descriptor). Now for discovery.impl such a 'strong cluster synchronization' guarantee is not that relevant as it might look. Since discovery.impl already uses the repository (and thus its delays) for voting and creating the establishedView. But at the moment there is no guarantee that the voting happens *after* the TOPOLOGY_CHANGING was processed by all listeners. It's just rather unlikely that sending the TOPOLOGY_CHANGING (which is all local) is slower than the voting (which is going through repository delays). Nevertheless, using the SyncTokenService would provide mentioned strong cluster synchronization guarantee and _discovery.impl could just as well make use of it_. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5231) Remove getAdministrativeResourceResolver() usage from Discovery components
[
https://issues.apache.org/jira/browse/SLING-5231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14987432#comment-14987432
]
Stefan Egli commented on SLING-5231:
there's also some in {{org.apache.sling.discovery.impl}}
> Remove getAdministrativeResourceResolver() usage from Discovery components
> --
>
> Key: SLING-5231
> URL: https://issues.apache.org/jira/browse/SLING-5231
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Reporter: Antonio Sanso
>Assignee: Stefan Egli
>
> * {{org.apache.sling.discovery.base}}: 6
> * {{org.apache.sling.discovery.commons}}: 3
> * {{org.apache.sling.discovery.oak}}: 4
> total of 13 occurrences
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (SLING-5231) Remove getAdministrativeResourceResolver() usage from Discovery components
[
https://issues.apache.org/jira/browse/SLING-5231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli reassigned SLING-5231:
--
Assignee: Stefan Egli
> Remove getAdministrativeResourceResolver() usage from Discovery components
> --
>
> Key: SLING-5231
> URL: https://issues.apache.org/jira/browse/SLING-5231
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Reporter: Antonio Sanso
>Assignee: Stefan Egli
>
> * {{org.apache.sling.discovery.base}}: 6
> * {{org.apache.sling.discovery.commons}}: 3
> * {{org.apache.sling.discovery.oak}}: 4
> total of 13 occurrences
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5251) discovery.impl should use SyncTokenService (configurable)
[ https://issues.apache.org/jira/browse/SLING-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli updated SLING-5251: --- Description: The SyncTokenService introduced with discovery.commons allows discovery implementors to add additional QoS to a TOPOLOGY_CHANGED event by waiting for each instance to store a 'sync token' (eg cluster *view* id, not cluster id) into the repository. The algorithm in detail: * upon detecting a topology change happening, each instance sends out TOPOLOGY_CHANGING to its listeners * *after* that is done, it stores a syncToken to a well-known place into the repository * thus when a particular instance sees all syncTokens by the peers, it knows that all listeners have now gotten the TOPOLOGY_CHANGING event - and that provides a strong synchronization guarantee. This mechanism is already in-use by default in discovery.oak (which additionally also ensures no instance has any backlog with the repository - which it can do as it requires oak and oak provides this info in the discovery-lite descriptor). Now for discovery.impl such a 'strong cluster synchronization' guarantee is not that relevant as it might look. Since discovery.impl already uses the repository (and thus its delays) for voting and creating the establishedView. But at the moment there is no guarantee that the voting happens *after* the TOPOLOGY_CHANGING was processed by all listeners. It's just rather unlikely that sending the TOPOLOGY_CHANGING (which is all local) is slower than the voting (which is going through repository delays). Nevertheless, using the SyncTokenService would provide mentioned strong cluster synchronization guarantee and _discovery.impl could just as well make use of it_. was: The SyncTokenService introduced with discovery.commons allows discovery implementors to add additional QoS to a TOPOLOGY_CHANGED event by waiting for each instance to store a 'sync token' (eg cluster *view* id, not cluster id) into the repository. Namely the following: * upon detecting a topology change happening, each instance sends out TOPOLOGY_CHANGING to its listeners * *after* that is done, it stores a syncToken to a well-known place into the repository * thus when a particular instance sees all syncTokens by the peers, it knows that all listeners have now gotten the TOPOLOGY_CHANGING event - and that provides a strong synchronization guarantee. This mechanism is already in-use by default in discovery.oak (which additionally also ensures no instance has any backlog with the repository - which it can do as it requires oak and oak provides this info in the discovery-lite descriptor). Now for discovery.impl such a 'strong cluster synchronization' guarantee is not that relevant as it might look. Since discovery.impl already uses the repository (and thus its delays) for voting and creating the establishedView. But at the moment there is no guarantee that the voting happens *after* the TOPOLOGY_CHANGING was processed by all listeners. It's just rather unlikely that sending the TOPOLOGY_CHANGING (which is all local) is slower than the voting (which is going through repository delays). Nevertheless, using the SyncTokenService would provide mentioned strong cluster synchronization guarantee and _discovery.impl could just as well make use of it_. > discovery.impl should use SyncTokenService (configurable) > - > > Key: SLING-5251 > URL: https://issues.apache.org/jira/browse/SLING-5251 > Project: Sling > Issue Type: Improvement > Components: Extensions >Affects Versions: Discovery Impl 1.2.0 >Reporter: Stefan Egli >Assignee: Stefan Egli > Fix For: Discovery Impl 1.2.2 > > > The SyncTokenService introduced with discovery.commons allows discovery > implementors to add additional QoS to a TOPOLOGY_CHANGED event by waiting for > each instance to store a 'sync token' (eg cluster *view* id, not cluster id) > into the repository. The algorithm in detail: > * upon detecting a topology change happening, each instance sends out > TOPOLOGY_CHANGING to its listeners > * *after* that is done, it stores a syncToken to a well-known place into the > repository > * thus when a particular instance sees all syncTokens by the peers, it knows > that all listeners have now gotten the TOPOLOGY_CHANGING event - and that > provides a strong synchronization guarantee. > This mechanism is already in-use by default in discovery.oak (which > additionally also ensures no instance has any backlog with the repository - > which it can do as it requires oak and oak provides this info in the > discovery-lite descriptor). > Now for discovery.impl such a 'strong cluster synchronization' guarantee is > not that relevant as it might look. Since discovery.impl already uses the >
[jira] [Commented] (SLING-2192) Support JAX-RS resource classes
[ https://issues.apache.org/jira/browse/SLING-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14987169#comment-14987169 ] Mike Rose commented on SLING-2192: -- I recently did this myself for a project. Let's just say it is "non-trivial". I will share a few notes here based on my experience. - I assembled a bundle that exports all the packages necessary to implement jax-rs 2.0 apis in any other bundles by importing the provided packages provided by my jax-rs bundle. This turned out to be a pretty good strategy. It kept the overall bundle bloat to a minimum and made implementing any number of bundles that each provided their own APIs fairly simple. - One challenge that I had to overcome is that the Sling Models API / Impl bundles have a bit of sloppiness in their manifests and export the javax.annotation package without specifying any version constraints. This caused a conflict when trying to supply the newer versions of that package and its sub-packages required by Jersey and Jackson. In the end, I had to build my own custom versions of org.apache.sling.models.api and org.apache.sling.models.impl as well as build my own custom launchpad that replaced the default versions of those bundles in order workaround the package conflicts. (should I file an issue about cleaning that up?) - I really did not like the approach taken by Caravan JAX-RS Publisher and OSGi JAX-RS Connector. They want you to overload OSGi services and expose them as JAX-RS resources which seems to violate the "single purpose per component" and KISS principles. They also don't seem to allow you to group your resources together in a ResourceConfig, making it hard to keep related resources grouped into a common path in their URIs or register any custom Providers. Instead, I implemented this so that I could deploy my APIs as I would in any other container and inject other services (OSGi or otherwise) into my JAX-RS resource classes. I can easily inject a resource resolver and/or resources adapted to pojos with Jackson annotations in order to serve up any sort of content. If anyone else thinks that they might find this useful I would be happy to share my implementation. Just drop me a line... > Support JAX-RS resource classes > --- > > Key: SLING-2192 > URL: https://issues.apache.org/jira/browse/SLING-2192 > Project: Sling > Issue Type: New Feature >Reporter: Reto Gmür > Attachments: SLING-2192-20110310.patch, SLING-2192-20111004.patch, > SLING-2192-20111013.patch, SLING-2192-new-jax-rs-bundle.patch, > SLING-2192-new-jax-rs-bundle.patch, > SLING-2192-with-sling-style-style-registration.patch, > SLING-2192-with-tests.patch, jaxrs-in-contrib.patch, slingr-on-wink-osgi.patch > > > It should be possible to register jax resource classes and providers as > services. As they don't implement a specific interface services that expose > java.lang.Object should be considered as javx-rs services iff they have the > service property "javax.ws.rs" set to true. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-5247) Update Jackrabbit to 2.11.2
[ https://issues.apache.org/jira/browse/SLING-5247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Lietz resolved SLING-5247. - Resolution: Done r1712238 r1712239 r1712240 > Update Jackrabbit to 2.11.2 > --- > > Key: SLING-5247 > URL: https://issues.apache.org/jira/browse/SLING-5247 > Project: Sling > Issue Type: Task > Components: JCR, Launchpad >Reporter: Oliver Lietz >Assignee: Oliver Lietz > Fix For: Launchpad Karaf Features 0.2.0, Launchpad Builder 9 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-5248) Update Oak to 1.3.9
[ https://issues.apache.org/jira/browse/SLING-5248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Lietz resolved SLING-5248. - Resolution: Done r1712241 r1712242 r1712243 r1712244 > Update Oak to 1.3.9 > --- > > Key: SLING-5248 > URL: https://issues.apache.org/jira/browse/SLING-5248 > Project: Sling > Issue Type: Task > Components: JCR, Launchpad >Reporter: Oliver Lietz >Assignee: Oliver Lietz > Fix For: Launchpad Karaf Features 0.2.0, JCR Oak Server 1.0.2, > Launchpad Builder 9 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5243) discovery.impl.cluster.SingleInstanceTest.testBootstrap failed on jenkins
[
https://issues.apache.org/jira/browse/SLING-5243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated SLING-5243:
---
Attachment: SingleInstanceTest.testBootstrap.failure1918.full.txt
Attaching non-truncated full
[^SingleInstanceTest.testBootstrap.failure1918.full.txt]
> discovery.impl.cluster.SingleInstanceTest.testBootstrap failed on jenkins
> -
>
> Key: SLING-5243
> URL: https://issues.apache.org/jira/browse/SLING-5243
> Project: Sling
> Issue Type: Bug
>Affects Versions: Discovery Impl 1.1.8
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Minor
> Fix For: Discovery Impl 1.2.2
>
> Attachments: SingleInstanceTest.testBootstrap.failure1918.full.txt,
> SingleInstanceTest.testBootstrap.failure1918.txt
>
>
> the following test failed:
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1918/testReport/junit/org.apache.sling.discovery.impl.cluster/SingleInstanceTest/testBootstrap/
> {code}
> Error Message
> expected:<1> but was:<0>
> Stacktrace
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.sling.discovery.base.its.AbstractSingleInstanceTest.testBootstrap(AbstractSingleInstanceTest.java:284)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5243) discovery.impl.cluster.SingleInstanceTest.testBootstrap failed on jenkins
[
https://issues.apache.org/jira/browse/SLING-5243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14987220#comment-14987220
]
Stefan Egli commented on SLING-5243:
the problem in this case is that during an {{analyzeVotings}} the test is
reading an {{/ongoingVotings}} resource in a non-consistent (transactionally
impossible) state: it looks like during creation of a new vote, the voting
handler is already seeing the changes - but only partially. That results in
{{voting.matchesLiveView}} to return false even though the voting hasn't been
fully created yet - which is then interpreted as: ok, I have to vote no. That
is wrong at that point, cos you shouldn't vote on a voting-in-creation.
However, that is never possible in real-life, it must be due to the way the
testing is setup.
The relevant part in the log file:
{code}
02.11.2015 15:25:00.689 *DEBUG* [main] HeartbeatHandler: doCheckViewWith: no
pending nor winning votes. But: view does not match established or no
established yet. Initiating a new voting
02.11.2015 15:25:00.689 *DEBUG* [main] HeartbeatHandler: doCheckViewWith: one
of the live instances is: 3e5791c1-31c7-4831-af73-843e5e15e478
02.11.2015 15:25:00.689 *INFO * [main] MockedResourceResolver: create: creating
of ongoingVotings under MockedResource, type=nt:unstructured,
path=/var/discovery/impl was successful=true
02.11.2015 15:25:00.696 *INFO * [main] MockedResourceResolver: create: creating
of d7ac3d95-6dda-448c-8759-888284717588 under MockedResource,
type=nt:unstructured, path=/var/discovery/impl/ongoin
gVotings was successful=true
[...]
02.11.2015 15:25:00.705 *DEBUG* [VotingEventListener-standaloneInstance]
VotingHelper: listVotings: votings found: 1
02.11.2015 15:25:00.705 *DEBUG* [VotingEventListener-standaloneInstance]
VotingView: getVotingStartTime: got a voting without votingStart. Likely in
creation: MockedResource, type=nt:unstructured
, path=/var/discovery/impl/ongoingVotings/d7ac3d95-6dda-448c-8759-888284717588
02.11.2015 15:25:00.705 *INFO * [VotingEventListener-standaloneInstance]
3e5791c1-31c7-4831-af73-843e5e15e478: analyzeVotings: vote doesnt match my live
view, voting no. comparison result: no mem
bers resource found, vote: a
VotingView[viewId=d7ac3d95-6dda-448c-8759-888284717588,
id=d7ac3d95-6dda-448c-8759-888284717588, initiator=null, members=]
[...]
02.11.2015 15:25:00.706 *INFO * [main] MockedResourceResolver: create: creating
of 3e5791c1-31c7-4831-af73-843e5e15e478 under MockedResource,
type=nt:unstructured,
path=/var/discovery/impl/ongoingVotings/d7ac3d95-6dda-448c-8759-888284717588/members
was successful=true
[...]
02.11.2015 15:25:00.713 *WARN * [main] ItemStateReferenceCache: overwriting
cached entry 6eab5bf1-34f9-4081-b03a-2ba0fc6ffc37/{}clusterIdDefinedAt
[...]
02.11.2015 15:25:00.715 *INFO * [main] VotingView: newVoting: new voting
started: newViewId=d7ac3d95-6dda-448c-8759-888284717588,
resource=MockedResource, type=nt:unstructured,
path=/var/discovery/impl/ongoingVotings/d7ac3d95-6dda-448c-8759-888284717588,
#members: 1, members: [3e5791c1-31c7-4831-af73-843e5e15e478]
{code}
> discovery.impl.cluster.SingleInstanceTest.testBootstrap failed on jenkins
> -
>
> Key: SLING-5243
> URL: https://issues.apache.org/jira/browse/SLING-5243
> Project: Sling
> Issue Type: Bug
>Affects Versions: Discovery Impl 1.1.8
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Minor
> Fix For: Discovery Impl 1.2.2
>
> Attachments: SingleInstanceTest.testBootstrap.failure1918.full.txt,
> SingleInstanceTest.testBootstrap.failure1918.txt
>
>
> the following test failed:
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1918/testReport/junit/org.apache.sling.discovery.impl.cluster/SingleInstanceTest/testBootstrap/
> {code}
> Error Message
> expected:<1> but was:<0>
> Stacktrace
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.sling.discovery.base.its.AbstractSingleInstanceTest.testBootstrap(AbstractSingleInstanceTest.java:284)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
[jira] [Commented] (SLING-5243) discovery.impl.cluster.SingleInstanceTest.testBootstrap failed on jenkins
[
https://issues.apache.org/jira/browse/SLING-5243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14987234#comment-14987234
]
Stefan Egli commented on SLING-5243:
Even though the test uses jackrabbit-core 2.2.9 (via sling.commons.testing
2.0.16) it looks like the WARN described in JCR-2813 is re-occurring in this
test.
> discovery.impl.cluster.SingleInstanceTest.testBootstrap failed on jenkins
> -
>
> Key: SLING-5243
> URL: https://issues.apache.org/jira/browse/SLING-5243
> Project: Sling
> Issue Type: Bug
>Affects Versions: Discovery Impl 1.1.8
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Minor
> Fix For: Discovery Impl 1.2.2
>
> Attachments: SingleInstanceTest.testBootstrap.failure1918.full.txt,
> SingleInstanceTest.testBootstrap.failure1918.txt
>
>
> the following test failed:
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1918/testReport/junit/org.apache.sling.discovery.impl.cluster/SingleInstanceTest/testBootstrap/
> {code}
> Error Message
> expected:<1> but was:<0>
> Stacktrace
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.sling.discovery.base.its.AbstractSingleInstanceTest.testBootstrap(AbstractSingleInstanceTest.java:284)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (SLING-4701) SlingAuthenticator.isAnonAllowed matches for all paths starting with the same characters
[ https://issues.apache.org/jira/browse/SLING-4701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus reassigned SLING-4701: -- Assignee: Konrad Windszus > SlingAuthenticator.isAnonAllowed matches for all paths starting with the same > characters > > > Key: SLING-4701 > URL: https://issues.apache.org/jira/browse/SLING-4701 > Project: Sling > Issue Type: Bug > Components: Authentication >Affects Versions: Auth Core 1.3.6 >Reporter: Lars Krapf >Assignee: Konrad Windszus > Labels: authentication > Attachments: SlingAuthenticator.patch, sling-4701-doc.patch > > > The SlingAuthenticator check if anonymous access is allowed compares paths > with String.startsWith. If the holder.path does not end with a '/' it will > erroneously match a different path that starts with the same characters, even > if it is not a descendant of the first path. > Example: > - Allow anonymous acces on '/' > - Deny anonymous access on a path '/blubb' > -> Authentication is enforced on a request to '/blubb-blah' - which is wrong. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5243) discovery.impl.cluster.SingleInstanceTest.testBootstrap failed on jenkins
[
https://issues.apache.org/jira/browse/SLING-5243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated SLING-5243:
---
Attachment: (was:
VotingHandlerTest.testConcurrentVotesTwoNodes.failure1918.txt)
> discovery.impl.cluster.SingleInstanceTest.testBootstrap failed on jenkins
> -
>
> Key: SLING-5243
> URL: https://issues.apache.org/jira/browse/SLING-5243
> Project: Sling
> Issue Type: Bug
>Affects Versions: Discovery Impl 1.1.8
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Minor
> Fix For: Discovery Impl 1.2.2
>
> Attachments: SingleInstanceTest.testBootstrap.failure1918.txt
>
>
> the following test failed:
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1918/testReport/junit/org.apache.sling.discovery.impl.cluster/SingleInstanceTest/testBootstrap/
> {code}
> Error Message
> expected:<1> but was:<0>
> Stacktrace
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.sling.discovery.base.its.AbstractSingleInstanceTest.testBootstrap(AbstractSingleInstanceTest.java:284)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (SLING-5243) discovery.impl.cluster.SingleInstanceTest.testBootstrap failed on jenkins
[
https://issues.apache.org/jira/browse/SLING-5243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated SLING-5243:
---
Comment: was deleted
(was: Attached [^VotingHandlerTest.testConcurrentVotesTwoNodes.failure1918.txt])
> discovery.impl.cluster.SingleInstanceTest.testBootstrap failed on jenkins
> -
>
> Key: SLING-5243
> URL: https://issues.apache.org/jira/browse/SLING-5243
> Project: Sling
> Issue Type: Bug
>Affects Versions: Discovery Impl 1.1.8
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Minor
> Fix For: Discovery Impl 1.2.2
>
> Attachments: SingleInstanceTest.testBootstrap.failure1918.txt
>
>
> the following test failed:
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1918/testReport/junit/org.apache.sling.discovery.impl.cluster/SingleInstanceTest/testBootstrap/
> {code}
> Error Message
> expected:<1> but was:<0>
> Stacktrace
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.sling.discovery.base.its.AbstractSingleInstanceTest.testBootstrap(AbstractSingleInstanceTest.java:284)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5134) Donation of sling pipes
[ https://issues.apache.org/jira/browse/SLING-5134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14987197#comment-14987197 ] Oliver Lietz commented on SLING-5134: - [~clr], [~npeltier] any news regarding the ICLA for this contribution? > Donation of sling pipes > --- > > Key: SLING-5134 > URL: https://issues.apache.org/jira/browse/SLING-5134 > Project: Sling > Issue Type: New Feature > Components: Extensions >Reporter: Nicolas Peltier >Assignee: Oliver Lietz > Attachments: sling-pipes.tar.gz > > > This issue tracks the donation of sling pipes as announced in [0]. Code & > documentation are there [1] https://github.com/npeltier/sling-pipes, two open > issues for now are tracked there a well [2] > [0] http://sling.markmail.org/thread/n6yr6upogruem7qp > [1] http://github.com/npeltier/sling-pipes > [2] https://github.com/npeltier/sling-pipes/issues -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4701) SlingAuthenticator.isAnonAllowed matches for all paths starting with the same characters
[ https://issues.apache.org/jira/browse/SLING-4701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago García Pimentel updated SLING-4701: Attachment: sling-4701-doc.patch thanks [~kwin]. Clarifying the doc also works for me. I think only the authentication framework page needs updating, but you know better. > SlingAuthenticator.isAnonAllowed matches for all paths starting with the same > characters > > > Key: SLING-4701 > URL: https://issues.apache.org/jira/browse/SLING-4701 > Project: Sling > Issue Type: Bug > Components: Authentication >Affects Versions: Auth Core 1.3.6 >Reporter: Lars Krapf > Labels: authentication > Attachments: SlingAuthenticator.patch, sling-4701-doc.patch > > > The SlingAuthenticator check if anonymous access is allowed compares paths > with String.startsWith. If the holder.path does not end with a '/' it will > erroneously match a different path that starts with the same characters, even > if it is not a descendant of the first path. > Example: > - Allow anonymous acces on '/' > - Deny anonymous access on a path '/blubb' > -> Authentication is enforced on a request to '/blubb-blah' - which is wrong. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5134) Donation of sling pipes
[ https://issues.apache.org/jira/browse/SLING-5134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14987232#comment-14987232 ] Nicolas Peltier commented on SLING-5134: Hey [~olli], i might have misunderstood / misread something, but Craig Russel told me ICLA was filed (& i mentioned that in the ticket) one week ago. Is there anything else i should do? > Donation of sling pipes > --- > > Key: SLING-5134 > URL: https://issues.apache.org/jira/browse/SLING-5134 > Project: Sling > Issue Type: New Feature > Components: Extensions >Reporter: Nicolas Peltier >Assignee: Oliver Lietz > Attachments: sling-pipes.tar.gz > > > This issue tracks the donation of sling pipes as announced in [0]. Code & > documentation are there [1] https://github.com/npeltier/sling-pipes, two open > issues for now are tracked there a well [2] > [0] http://sling.markmail.org/thread/n6yr6upogruem7qp > [1] http://github.com/npeltier/sling-pipes > [2] https://github.com/npeltier/sling-pipes/issues -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-4701) SlingAuthenticator.isAnonAllowed matches for all paths starting with the same characters
[ https://issues.apache.org/jira/browse/SLING-4701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14987247#comment-14987247 ] Konrad Windszus edited comment on SLING-4701 at 11/3/15 1:17 PM: - I applied a slightly different version of [~santiagozky]'s documentation patch. Please check the new documentation at https://sling.apache.org/documentation/the-sling-engine/authentication/authentication-framework.html#anonymous-login. I am closing this bug as "Invalid" as a change here would not be backward-compatible and there is a valid workaround for the original issue. was (Author: kwin): I applied a slightly different version of [~santiagozky]'s patch. Please check the new documentation at https://sling.apache.org/documentation/the-sling-engine/authentication/authentication-framework.html#anonymous-login. I am closing this bug as "Invalid" as a change here would not be backward-compatible and there is a valid workaround for the original issue. > SlingAuthenticator.isAnonAllowed matches for all paths starting with the same > characters > > > Key: SLING-4701 > URL: https://issues.apache.org/jira/browse/SLING-4701 > Project: Sling > Issue Type: Bug > Components: Authentication >Affects Versions: Auth Core 1.3.6 >Reporter: Lars Krapf >Assignee: Konrad Windszus > Labels: authentication > Attachments: SlingAuthenticator.patch, sling-4701-doc.patch > > > The SlingAuthenticator check if anonymous access is allowed compares paths > with String.startsWith. If the holder.path does not end with a '/' it will > erroneously match a different path that starts with the same characters, even > if it is not a descendant of the first path. > Example: > - Allow anonymous acces on '/' > - Deny anonymous access on a path '/blubb' > -> Authentication is enforced on a request to '/blubb-blah' - which is wrong. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5134) Donation of sling pipes
[ https://issues.apache.org/jira/browse/SLING-5134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14987250#comment-14987250 ] Oliver Lietz commented on SLING-5134: - We usually get a copy of the message from [~clr] at private@ but I didn't see it. Will check the archive. > Donation of sling pipes > --- > > Key: SLING-5134 > URL: https://issues.apache.org/jira/browse/SLING-5134 > Project: Sling > Issue Type: New Feature > Components: Extensions >Reporter: Nicolas Peltier >Assignee: Oliver Lietz > Attachments: sling-pipes.tar.gz > > > This issue tracks the donation of sling pipes as announced in [0]. Code & > documentation are there [1] https://github.com/npeltier/sling-pipes, two open > issues for now are tracked there a well [2] > [0] http://sling.markmail.org/thread/n6yr6upogruem7qp > [1] http://github.com/npeltier/sling-pipes > [2] https://github.com/npeltier/sling-pipes/issues -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-5243) discovery.impl.cluster.SingleInstanceTest.testBootstrap failed on jenkins
[
https://issues.apache.org/jira/browse/SLING-5243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14987231#comment-14987231
]
Stefan Egli edited comment on SLING-5243 at 11/3/15 1:06 PM:
-
The fix consists of two parts:
* {{View.matches}} and {{View.matchesLiveView}} should throw an Exception when
what they read is not consistent - instead of swallowing that and returning
false
* {{analyzeVotings}} should first do {{isOngoingVoting}} before comparing the
live view - as that would also have avoided the false-no-vote this time and is
anyway the more resilient way
was (Author: egli):
The fix consists of two parts:
* {{View.matches]} and {{View.matchesLiveView}} should throw an Exception when
what they read is not consistent - instead of swallowing that and returning
false
* {{analyzeVotings}} should first do {{isOngoingVoting}} before comparing the
live view - as that would also have avoided the false-no-vote this time and is
anyway the more resilient way
> discovery.impl.cluster.SingleInstanceTest.testBootstrap failed on jenkins
> -
>
> Key: SLING-5243
> URL: https://issues.apache.org/jira/browse/SLING-5243
> Project: Sling
> Issue Type: Bug
>Affects Versions: Discovery Impl 1.1.8
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Minor
> Fix For: Discovery Impl 1.2.2
>
> Attachments: SingleInstanceTest.testBootstrap.failure1918.full.txt,
> SingleInstanceTest.testBootstrap.failure1918.txt
>
>
> the following test failed:
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1918/testReport/junit/org.apache.sling.discovery.impl.cluster/SingleInstanceTest/testBootstrap/
> {code}
> Error Message
> expected:<1> but was:<0>
> Stacktrace
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.sling.discovery.base.its.AbstractSingleInstanceTest.testBootstrap(AbstractSingleInstanceTest.java:284)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5243) discovery.impl.cluster.SingleInstanceTest.testBootstrap failed on jenkins
[
https://issues.apache.org/jira/browse/SLING-5243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14987231#comment-14987231
]
Stefan Egli commented on SLING-5243:
The fix consists of two parts:
* {{View.matches]} and {{View.matchesLiveView}} should throw an Exception when
what they read is not consistent - instead of swallowing that and returning
false
* {{analyzeVotings}} should first do {{isOngoingVoting}} before comparing the
live view - as that would also have avoided the false-no-vote this time and is
anyway the more resilient way
> discovery.impl.cluster.SingleInstanceTest.testBootstrap failed on jenkins
> -
>
> Key: SLING-5243
> URL: https://issues.apache.org/jira/browse/SLING-5243
> Project: Sling
> Issue Type: Bug
>Affects Versions: Discovery Impl 1.1.8
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Minor
> Fix For: Discovery Impl 1.2.2
>
> Attachments: SingleInstanceTest.testBootstrap.failure1918.full.txt,
> SingleInstanceTest.testBootstrap.failure1918.txt
>
>
> the following test failed:
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1918/testReport/junit/org.apache.sling.discovery.impl.cluster/SingleInstanceTest/testBootstrap/
> {code}
> Error Message
> expected:<1> but was:<0>
> Stacktrace
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.sling.discovery.base.its.AbstractSingleInstanceTest.testBootstrap(AbstractSingleInstanceTest.java:284)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-5243) discovery.impl.cluster.SingleInstanceTest.testBootstrap failed on jenkins
[
https://issues.apache.org/jira/browse/SLING-5243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli resolved SLING-5243.
Resolution: Fixed
fixed in rev 1712291
> discovery.impl.cluster.SingleInstanceTest.testBootstrap failed on jenkins
> -
>
> Key: SLING-5243
> URL: https://issues.apache.org/jira/browse/SLING-5243
> Project: Sling
> Issue Type: Bug
>Affects Versions: Discovery Impl 1.1.8
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Minor
> Fix For: Discovery Impl 1.2.2
>
> Attachments: SingleInstanceTest.testBootstrap.failure1918.full.txt,
> SingleInstanceTest.testBootstrap.failure1918.txt
>
>
> the following test failed:
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1918/testReport/junit/org.apache.sling.discovery.impl.cluster/SingleInstanceTest/testBootstrap/
> {code}
> Error Message
> expected:<1> but was:<0>
> Stacktrace
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.sling.discovery.base.its.AbstractSingleInstanceTest.testBootstrap(AbstractSingleInstanceTest.java:284)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-4701) SlingAuthenticator.isAnonAllowed matches for all paths starting with the same characters
[ https://issues.apache.org/jira/browse/SLING-4701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved SLING-4701. Resolution: Invalid > SlingAuthenticator.isAnonAllowed matches for all paths starting with the same > characters > > > Key: SLING-4701 > URL: https://issues.apache.org/jira/browse/SLING-4701 > Project: Sling > Issue Type: Bug > Components: Authentication >Affects Versions: Auth Core 1.3.6 >Reporter: Lars Krapf >Assignee: Konrad Windszus > Labels: authentication > Attachments: SlingAuthenticator.patch, sling-4701-doc.patch > > > The SlingAuthenticator check if anonymous access is allowed compares paths > with String.startsWith. If the holder.path does not end with a '/' it will > erroneously match a different path that starts with the same characters, even > if it is not a descendant of the first path. > Example: > - Allow anonymous acces on '/' > - Deny anonymous access on a path '/blubb' > -> Authentication is enforced on a request to '/blubb-blah' - which is wrong. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4701) SlingAuthenticator.isAnonAllowed matches for all paths starting with the same characters
[ https://issues.apache.org/jira/browse/SLING-4701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14987247#comment-14987247 ] Konrad Windszus commented on SLING-4701: I applied a slightly different version of [~santiagozky]'s patch. Please check the new documentation at https://sling.apache.org/documentation/the-sling-engine/authentication/authentication-framework.html#anonymous-login. I am closing this bug as "Invalid" as a change here would not be backward-compatible and there is a valid workaround for the original issue. > SlingAuthenticator.isAnonAllowed matches for all paths starting with the same > characters > > > Key: SLING-4701 > URL: https://issues.apache.org/jira/browse/SLING-4701 > Project: Sling > Issue Type: Bug > Components: Authentication >Affects Versions: Auth Core 1.3.6 >Reporter: Lars Krapf >Assignee: Konrad Windszus > Labels: authentication > Attachments: SlingAuthenticator.patch, sling-4701-doc.patch > > > The SlingAuthenticator check if anonymous access is allowed compares paths > with String.startsWith. If the holder.path does not end with a '/' it will > erroneously match a different path that starts with the same characters, even > if it is not a descendant of the first path. > Example: > - Allow anonymous acces on '/' > - Deny anonymous access on a path '/blubb' > -> Authentication is enforced on a request to '/blubb-blah' - which is wrong. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5244) discovery.impl.cluster.voting.VotingHandlerTest.testConcurrentVotesTwoNodes failed on jenkins
[
https://issues.apache.org/jira/browse/SLING-5244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated SLING-5244:
---
Attachment: VotingHandlerTest.testConcurrentVotesTwoNodes.failure1918.txt
Attached [^VotingHandlerTest.testConcurrentVotesTwoNodes.failure1918.txt]
> discovery.impl.cluster.voting.VotingHandlerTest.testConcurrentVotesTwoNodes
> failed on jenkins
> -
>
> Key: SLING-5244
> URL: https://issues.apache.org/jira/browse/SLING-5244
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Discovery Impl 1.1.8
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Impl 1.2.2
>
> Attachments:
> VotingHandlerTest.testConcurrentVotesTwoNodes.failure1918.txt
>
>
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1918/testReport/junit/org.apache.sling.discovery.impl.cluster.voting/VotingHandlerTest/testConcurrentVotesTwoNodes/
> {code}
> Error Message
> expected:<456> but was:<455>
> Stacktrace
> java.lang.AssertionError: expected:<456> but was:<455>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.sling.discovery.impl.cluster.voting.VotingHandlerTest.doTestConcurrentVotes(VotingHandlerTest.java:466)
> at
> org.apache.sling.discovery.impl.cluster.voting.VotingHandlerTest.testConcurrentVotesTwoNodes(VotingHandlerTest.java:322)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4701) SlingAuthenticator.isAnonAllowed matches for all paths starting with the same characters
[
https://issues.apache.org/jira/browse/SLING-4701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14987147#comment-14987147
]
Konrad Windszus commented on SLING-4701:
I came to the conclusion that both the {{sling.auth.requirements}}
(https://sling.apache.org/documentation/the-sling-engine/authentication/authentication-framework.html#anonymous-login)
as well as the {{AuthenticationHandler}} path
(https://sling.apache.org/documentation/the-sling-engine/authentication/authentication-authenticationhandler.html)
are only used to be compared against the request path.
The request path for resource '/blubb' or subresources may look like any of the
following:
* /blubb.html
* /blubb.selector.html
* /blubb.html/suffix
Both patches don't look correct to me (because some of the above mentioned
cases are not covered).
I would therefore rather clarify in the documentation that there is a
comparison if the request path starts with the given path and then leave it at
that.
To cover the case from above where you want to allow anonymous access to
'/blubb' but not '/blubb-blah' you would have to give the following
{{sling.auth.requirements}}:
# /blubb/
# /blubb.html (if necessary)
> SlingAuthenticator.isAnonAllowed matches for all paths starting with the same
> characters
>
>
> Key: SLING-4701
> URL: https://issues.apache.org/jira/browse/SLING-4701
> Project: Sling
> Issue Type: Bug
> Components: Authentication
>Affects Versions: Auth Core 1.3.6
>Reporter: Lars Krapf
> Labels: authentication
> Attachments: SlingAuthenticator.patch
>
>
> The SlingAuthenticator check if anonymous access is allowed compares paths
> with String.startsWith. If the holder.path does not end with a '/' it will
> erroneously match a different path that starts with the same characters, even
> if it is not a descendant of the first path.
> Example:
> - Allow anonymous acces on '/'
> - Deny anonymous access on a path '/blubb'
> -> Authentication is enforced on a request to '/blubb-blah' - which is wrong.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5210) Create an installer factory/transformer for slingstart-maven-plugin generated intermediary subsystem files
[ https://issues.apache.org/jira/browse/SLING-5210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14986994#comment-14986994 ] Carsten Ziegeler commented on SLING-5210: - Code looks good to me, sounds like a nice addition > Create an installer factory/transformer for slingstart-maven-plugin generated > intermediary subsystem files > -- > > Key: SLING-5210 > URL: https://issues.apache.org/jira/browse/SLING-5210 > Project: Sling > Issue Type: Task > Components: Installer >Reporter: David Bosschaert > Attachments: subsystem_base.zip > > > Because run modes determine the actual content deployed at runtime, the > slingstart-maven-plugin cannot directly generate .esa files from the > provisioning model. It generates an intermediary format which can be > transformed into an subsystem .esa file at runtime once the current run modes > are known. This JIRA is to generate the transformer to do this work at run > time. > More details on SLING-5149 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4831) Clarify topology connectors are cross-cluster, not intra-cluster
[ https://issues.apache.org/jira/browse/SLING-4831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli resolved SLING-4831. Resolution: Fixed Adjusted documentation in http://svn.apache.org/viewvc?rev=1712247=rev (should be visible soon at https://sling.apache.org/documentation/bundles/discovery-api-and-impl.html) > Clarify topology connectors are cross-cluster, not intra-cluster > > > Key: SLING-4831 > URL: https://issues.apache.org/jira/browse/SLING-4831 > Project: Sling > Issue Type: Task > Components: Extensions >Reporter: Stefan Egli >Assignee: Stefan Egli > > It was voiced that > https://sling.apache.org/documentation/bundles/discovery-api-and-impl.html > does not point out clearly enough that connectors are cross-cluster and not > intra-cluster. Make this point thus clearer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5231) Remove getAdministrativeResourceResolver() usage from Discovery components
[
https://issues.apache.org/jira/browse/SLING-5231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated SLING-5231:
---
Affects Version/s: Discovery Impl 1.2.0
> Remove getAdministrativeResourceResolver() usage from Discovery components
> --
>
> Key: SLING-5231
> URL: https://issues.apache.org/jira/browse/SLING-5231
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: Discovery Impl 1.2.0, Discovery Oak 1.0.2, Discovery
> Base 1.0.2, Discovery Commons 1.0.2
>Reporter: Antonio Sanso
>Assignee: Stefan Egli
> Fix For: Discovery Impl 1.2.2, Discovery Commons 1.0.4, Discovery
> Base 1.0.4, Discovery Oak 1.0.4
>
>
> * {{org.apache.sling.discovery.base}}: 6
> * {{org.apache.sling.discovery.commons}}: 3
> * {{org.apache.sling.discovery.oak}}: 4
> total of 13 occurrences
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5231) Remove getAdministrativeResourceResolver() usage from Discovery components
[
https://issues.apache.org/jira/browse/SLING-5231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated SLING-5231:
---
Fix Version/s: Discovery Impl 1.2.2
> Remove getAdministrativeResourceResolver() usage from Discovery components
> --
>
> Key: SLING-5231
> URL: https://issues.apache.org/jira/browse/SLING-5231
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: Discovery Impl 1.2.0, Discovery Oak 1.0.2, Discovery
> Base 1.0.2, Discovery Commons 1.0.2
>Reporter: Antonio Sanso
>Assignee: Stefan Egli
> Fix For: Discovery Impl 1.2.2, Discovery Commons 1.0.4, Discovery
> Base 1.0.4, Discovery Oak 1.0.4
>
>
> * {{org.apache.sling.discovery.base}}: 6
> * {{org.apache.sling.discovery.commons}}: 3
> * {{org.apache.sling.discovery.oak}}: 4
> total of 13 occurrences
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5231) Remove getAdministrativeResourceResolver() usage from Discovery components
[
https://issues.apache.org/jira/browse/SLING-5231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated SLING-5231:
---
Affects Version/s: Discovery Commons 1.0.2
Discovery Base 1.0.2
Discovery Oak 1.0.2
> Remove getAdministrativeResourceResolver() usage from Discovery components
> --
>
> Key: SLING-5231
> URL: https://issues.apache.org/jira/browse/SLING-5231
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: Discovery Oak 1.0.2, Discovery Base 1.0.2, Discovery
> Commons 1.0.2
>Reporter: Antonio Sanso
>Assignee: Stefan Egli
> Fix For: Discovery Commons 1.0.4, Discovery Base 1.0.4, Discovery
> Oak 1.0.4
>
>
> * {{org.apache.sling.discovery.base}}: 6
> * {{org.apache.sling.discovery.commons}}: 3
> * {{org.apache.sling.discovery.oak}}: 4
> total of 13 occurrences
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5231) Remove getAdministrativeResourceResolver() usage from Discovery components
[
https://issues.apache.org/jira/browse/SLING-5231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated SLING-5231:
---
Fix Version/s: Discovery Oak 1.0.4
Discovery Base 1.0.4
Discovery Commons 1.0.4
> Remove getAdministrativeResourceResolver() usage from Discovery components
> --
>
> Key: SLING-5231
> URL: https://issues.apache.org/jira/browse/SLING-5231
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: Discovery Oak 1.0.2, Discovery Base 1.0.2, Discovery
> Commons 1.0.2
>Reporter: Antonio Sanso
>Assignee: Stefan Egli
> Fix For: Discovery Commons 1.0.4, Discovery Base 1.0.4, Discovery
> Oak 1.0.4
>
>
> * {{org.apache.sling.discovery.base}}: 6
> * {{org.apache.sling.discovery.commons}}: 3
> * {{org.apache.sling.discovery.oak}}: 4
> total of 13 occurrences
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5014) Uninstall directive in provisioning model might just lead to downgrade of bundle
[ https://issues.apache.org/jira/browse/SLING-5014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14987917#comment-14987917 ] Carsten Ziegeler commented on SLING-5014: - We definitely need a way where you can override the info from the uninstall section. We already had the use case where someone wanted to reinstall a bundle which was removed by the uninstall section on startup > Uninstall directive in provisioning model might just lead to downgrade of > bundle > > > Key: SLING-5014 > URL: https://issues.apache.org/jira/browse/SLING-5014 > Project: Sling > Issue Type: Bug > Components: Installer >Affects Versions: Installer Core 3.6.6 >Reporter: Dominik Süß > Attachments: SLING-5014-1.diff > > > In case a bundle has mutliple install candiates only the highest version > (with the highest priorty for the same versions) wins. An uninstall directive > uninstalls this version. The way the OSGi install behavior is defined this > lets the next artifact in the priority queue to get active and consequently > only leads to downgrade to the next in the queue. > As the uninstall directive declares a range that should be uninstalled the > expectation is that after a startup with such an uninstall directive none of > the delcared versions are in an installed state. In consequence the OSGi > installer must save this metainformation in the state that prevents a > downgrade to a version that is part of an active uninstall directive. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5014) Uninstall directive in provisioning model might just lead to downgrade of bundle
[ https://issues.apache.org/jira/browse/SLING-5014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14988385#comment-14988385 ] Dominik Süß commented on SLING-5014: [~cziegeler] - this patch is more about granting that the uninstall directives really are taken into account. Although the OSGi config allows to override the uninstall directives as blacklist definitions the current implementation does not prevent uninstallation by the bootstrap installer on next startup. We could think about an alternative way of defining the "amendment"/override of sling_bootstrap.txt in an install location that would need to be looked up before the bootstrap installer kicks in. This definition then should be respected by the blacklist service as well (just like utilizing sling_bootstrap.txt right now) It would anyways be great if you could have a quick look at my implementation as I want to make sure I haven't missed scenarios. Note: this is more of a safety net for scenarios where installables are present that shouldn't be installed. The various different ways we have to provide installables lead to a state where it is not unlikely (and multiple time observed) that this safety net needs to kick in. > Uninstall directive in provisioning model might just lead to downgrade of > bundle > > > Key: SLING-5014 > URL: https://issues.apache.org/jira/browse/SLING-5014 > Project: Sling > Issue Type: Bug > Components: Installer >Affects Versions: Installer Core 3.6.6 >Reporter: Dominik Süß > Attachments: SLING-5014-1.diff > > > In case a bundle has mutliple install candiates only the highest version > (with the highest priorty for the same versions) wins. An uninstall directive > uninstalls this version. The way the OSGi install behavior is defined this > lets the next artifact in the priority queue to get active and consequently > only leads to downgrade to the next in the queue. > As the uninstall directive declares a range that should be uninstalled the > expectation is that after a startup with such an uninstall directive none of > the delcared versions are in an installed state. In consequence the OSGi > installer must save this metainformation in the state that prevents a > downgrade to a version that is part of an active uninstall directive. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-2192) Support JAX-RS resource classes
[
https://issues.apache.org/jira/browse/SLING-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14988350#comment-14988350
]
Stefan Seifert commented on SLING-2192:
---
{quote}
One challenge that I had to overcome is that the Sling Models API / Impl
bundles have a bit of sloppiness in their manifests and export the
javax.annotation package without specifying any version constraints
{quote}
which version of sling models did you use? this should be fixed with SLING-4710
/ sling models API 1.2.0.
> Support JAX-RS resource classes
> ---
>
> Key: SLING-2192
> URL: https://issues.apache.org/jira/browse/SLING-2192
> Project: Sling
> Issue Type: New Feature
>Reporter: Reto Gmür
> Attachments: SLING-2192-20110310.patch, SLING-2192-20111004.patch,
> SLING-2192-20111013.patch, SLING-2192-new-jax-rs-bundle.patch,
> SLING-2192-new-jax-rs-bundle.patch,
> SLING-2192-with-sling-style-style-registration.patch,
> SLING-2192-with-tests.patch, jaxrs-in-contrib.patch, slingr-on-wink-osgi.patch
>
>
> It should be possible to register jax resource classes and providers as
> services. As they don't implement a specific interface services that expose
> java.lang.Object should be considered as javx-rs services iff they have the
> service property "javax.ws.rs" set to true.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-5255) Jobs: allow to configure queue.maxparallel in terms of % of number of CPU cores
Alexander Klimetschek created SLING-5255:
Summary: Jobs: allow to configure queue.maxparallel in terms of %
of number of CPU cores
Key: SLING-5255
URL: https://issues.apache.org/jira/browse/SLING-5255
Project: Sling
Issue Type: Improvement
Components: Extensions
Reporter: Alexander Klimetschek
The {{queue.maxparallel}} setting (how many concurrent threads can run for a
given job queue) currently supports a fixed number of threads or -1 which means
"as many CPU cores present on the machine". The latter is in our case used as a
crucial default, but it's too aggressive, since it might take over all CPU
processing.
Since every machine has different numbers of CPUs and cores, it would be useful
to express this config as % of number of CPU cores. This allows for example for
a default setting of 50% that should work well on different machines without
having to manually configure it on each instance.
This could either be a separate setting or (better) maybe allow floating point
numbers between 0.0 and 1.0 to express the percentage for the existing
{{queue.maxparallel}}. E.g. 0.5 means 50% of the cores. If it's an integer,
continue to use it as an exact number of threads to use.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5248) Update Oak to 1.3.9
[ https://issues.apache.org/jira/browse/SLING-5248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14988076#comment-14988076 ] Oliver Lietz commented on SLING-5248: - r1712398 r1712400 > Update Oak to 1.3.9 > --- > > Key: SLING-5248 > URL: https://issues.apache.org/jira/browse/SLING-5248 > Project: Sling > Issue Type: Task > Components: JCR, Launchpad >Reporter: Oliver Lietz >Assignee: Oliver Lietz > Fix For: Launchpad Karaf Features 0.2.0, JCR Oak Server 1.0.2, > Launchpad Builder 9 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-2192) Support JAX-RS resource classes
[ https://issues.apache.org/jira/browse/SLING-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14988877#comment-14988877 ] Mike Rose commented on SLING-2192: -- I had been working off of trunk/master for a while and have been working off of launchpad 8 since it was released. Launchpad 8 depends on v 1.2.2 of the Sling Models api/impl. Here are the relevant excerpts from the manifest of Sling Model api: Import-Package: > javax.annotation,javax.inject < Export-Package: org.apache.sling.models.annotations;version="1.2.0";uses:="javax.inject", org.apache.sling.models.annotations.injectorspecific;version="1.1.0";uses:="org.apache.sling.models.annotations,org.apache.sling.models.spi.injectorspecific". > org.apache.sling.models.factory;version="1.1.0";uses:="javax.annotation", < org.apache.sling.models.spi;version="1.1.1";uses:="javax.annotation,org.apache.sling.models.factory", org.apache.sling.models.spi.injectorspecific;version="1.1.1";uses:="org.apache.sling.models.annotations.injectorspecific" I added the following import to the Maven Bundle Plugin configuration in Sling Models api to resolve this: javax.annotation;version="[0,1)" This directs this bundle to only try to import (and then in turn export) only the version of the javax.annotation package supplied with the Felix OSGi Framework bundles. Then I could supply the 1.2 version of that package from my JAX-RS enabling bundle without conflict. I will freely admit that I am new to both Sling and OSGi and could be misinterpreting what I have observed and may be going about resolving this entirely the wrong way. I will gladly accept any insight or advice you can offer. > Support JAX-RS resource classes > --- > > Key: SLING-2192 > URL: https://issues.apache.org/jira/browse/SLING-2192 > Project: Sling > Issue Type: New Feature >Reporter: Reto Gmür > Attachments: SLING-2192-20110310.patch, SLING-2192-20111004.patch, > SLING-2192-20111013.patch, SLING-2192-new-jax-rs-bundle.patch, > SLING-2192-new-jax-rs-bundle.patch, > SLING-2192-with-sling-style-style-registration.patch, > SLING-2192-with-tests.patch, jaxrs-in-contrib.patch, slingr-on-wink-osgi.patch > > > It should be possible to register jax resource classes and providers as > services. As they don't implement a specific interface services that expose > java.lang.Object should be considered as javx-rs services iff they have the > service property "javax.ws.rs" set to true. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-3793) Field in MimeTypeServiceImpl must be declared volatile
[ https://issues.apache.org/jira/browse/SLING-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14988834#comment-14988834 ] Tien commented on SLING-3793: - Hi [~cziegeler] Recently i do research on Apache Sling, i found many cool stuff here. I have a question: can you explain why logService should be declared as volatile. Regards, Tien Nguyen. > Field in MimeTypeServiceImpl must be declared volatile > -- > > Key: SLING-3793 > URL: https://issues.apache.org/jira/browse/SLING-3793 > Project: Sling > Issue Type: Bug > Components: Commons >Affects Versions: Commons Mime 2.1.4 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Commons Mime 2.1.6 > > > The field logService must be declared as volatile -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-2192) Support JAX-RS resource classes
[
https://issues.apache.org/jira/browse/SLING-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14988877#comment-14988877
]
Mike Rose edited comment on SLING-2192 at 11/4/15 4:56 AM:
---
I had been working off of trunk/master for a while and have been working off of
launchpad 8 since it was released. Launchpad 8 depends on v 1.2.2 of the Sling
Models api/impl. Here are the relevant excerpts from the manifest of Sling
Model api:
{noformat}
Import-Package:
> javax.annotation,javax.inject <
Export-Package:
org.apache.sling.models.annotations;version="1.2.0";uses:="javax.inject",
org.apache.sling.models.annotations.injectorspecific;version="1.1.0";uses:="org.apache.sling.models.annotations,org.apache.sling.models.spi.injectorspecific".
>
org.apache.sling.models.factory;version="1.1.0";uses:="javax.annotation",
<
org.apache.sling.models.spi;version="1.1.1";uses:="javax.annotation,org.apache.sling.models.factory",
org.apache.sling.models.spi.injectorspecific;version="1.1.1";uses:="org.apache.sling.models.annotations.injectorspecific"
{noformat}
I added the following import to the Maven Bundle Plugin configuration in Sling
Models api to resolve this:
{code:xml}
javax.annotation;version="[0,1)"
{code}
This directs this bundle to only try to import (and then in turn export) only
the version of the javax.annotation package supplied with the Felix OSGi
Framework bundles. Then I could supply the 1.2 version of that package from my
JAX-RS enabling bundle without conflict.
I will freely admit that I am new to both Sling and OSGi and could be
misinterpreting what I have observed and may be going about resolving this
entirely the wrong way. I will gladly accept any insight or advice you can
offer.
was (Author: mutsys):
I had been working off of trunk/master for a while and have been working off of
launchpad 8 since it was released. Launchpad 8 depends on v 1.2.2 of the Sling
Models api/impl. Here are the relevant excerpts from the manifest of Sling
Model api:
Import-Package:
> javax.annotation,javax.inject <
Export-Package:
org.apache.sling.models.annotations;version="1.2.0";uses:="javax.inject",
org.apache.sling.models.annotations.injectorspecific;version="1.1.0";uses:="org.apache.sling.models.annotations,org.apache.sling.models.spi.injectorspecific".
>
org.apache.sling.models.factory;version="1.1.0";uses:="javax.annotation",
<
org.apache.sling.models.spi;version="1.1.1";uses:="javax.annotation,org.apache.sling.models.factory",
org.apache.sling.models.spi.injectorspecific;version="1.1.1";uses:="org.apache.sling.models.annotations.injectorspecific"
I added the following import to the Maven Bundle Plugin configuration in Sling
Models api to resolve this:
javax.annotation;version="[0,1)"
This directs this bundle to only try to import (and then in turn export) only
the version of the javax.annotation package supplied with the Felix OSGi
Framework bundles. Then I could supply the 1.2 version of that package from my
JAX-RS enabling bundle without conflict.
I will freely admit that I am new to both Sling and OSGi and could be
misinterpreting what I have observed and may be going about resolving this
entirely the wrong way. I will gladly accept any insight or advice you can
offer.
> Support JAX-RS resource classes
> ---
>
> Key: SLING-2192
> URL: https://issues.apache.org/jira/browse/SLING-2192
> Project: Sling
> Issue Type: New Feature
>Reporter: Reto Gmür
> Attachments: SLING-2192-20110310.patch, SLING-2192-20111004.patch,
> SLING-2192-20111013.patch, SLING-2192-new-jax-rs-bundle.patch,
> SLING-2192-new-jax-rs-bundle.patch,
> SLING-2192-with-sling-style-style-registration.patch,
> SLING-2192-with-tests.patch, jaxrs-in-contrib.patch, slingr-on-wink-osgi.patch
>
>
> It should be possible to register jax resource classes and providers as
> services. As they don't implement a specific interface services that expose
> java.lang.Object should be considered as javx-rs services iff they have the
> service property "javax.ws.rs" set to true.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-3793) Field in MimeTypeServiceImpl must be declared volatile
[ https://issues.apache.org/jira/browse/SLING-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14989023#comment-14989023 ] Carsten Ziegeler commented on SLING-3793: - The field is holding a dynamic reference - so this field can change over time. Whenever the log service gets available it is set to the service instance, when the log service gets unavailable (e.g. if the log bundle is updated) it gets set to null. Volatile is required in this case to make this change visible not only to the thread changing the field, but to all threads using the mime type service > Field in MimeTypeServiceImpl must be declared volatile > -- > > Key: SLING-3793 > URL: https://issues.apache.org/jira/browse/SLING-3793 > Project: Sling > Issue Type: Bug > Components: Commons >Affects Versions: Commons Mime 2.1.4 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Commons Mime 2.1.6 > > > The field logService must be declared as volatile -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (SLING-3793) Field in MimeTypeServiceImpl must be declared volatile
[ https://issues.apache.org/jira/browse/SLING-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-3793: Comment: was deleted (was: The field is holding a dynamic reference - so this field can change over time. Whenever the log service gets available it is set to the service instance, when the log service gets unavailable (e.g. if the log bundle is updated) it gets set to null. Volatile is required in this case to make this change visible not only to the thread changing the field, but to all threads using the mime type service) > Field in MimeTypeServiceImpl must be declared volatile > -- > > Key: SLING-3793 > URL: https://issues.apache.org/jira/browse/SLING-3793 > Project: Sling > Issue Type: Bug > Components: Commons >Affects Versions: Commons Mime 2.1.4 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Commons Mime 2.1.6 > > > The field logService must be declared as volatile -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-3793) Field in MimeTypeServiceImpl must be declared volatile
[ https://issues.apache.org/jira/browse/SLING-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14989022#comment-14989022 ] Carsten Ziegeler commented on SLING-3793: - The field is holding a dynamic reference - so this field can change over time. Whenever the log service gets available it is set to the service instance, when the log service gets unavailable (e.g. if the log bundle is updated) it gets set to null. Volatile is required in this case to make this change visible not only to the thread changing the field, but to all threads using the mime type service > Field in MimeTypeServiceImpl must be declared volatile > -- > > Key: SLING-3793 > URL: https://issues.apache.org/jira/browse/SLING-3793 > Project: Sling > Issue Type: Bug > Components: Commons >Affects Versions: Commons Mime 2.1.4 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Commons Mime 2.1.6 > > > The field logService must be declared as volatile -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-5244) discovery.impl.cluster.voting.VotingHandlerTest.testConcurrentVotesTwoNodes failed on jenkins
[
https://issues.apache.org/jira/browse/SLING-5244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli resolved SLING-5244.
Resolution: Fixed
fixed the test in rev 1712302:
when the concurrent voting results in one votingHandler to finish
analyzeVotings before the other starts, there is no NO vote by the initiator of
the voting - so the failing assertion was indeed wrong
> discovery.impl.cluster.voting.VotingHandlerTest.testConcurrentVotesTwoNodes
> failed on jenkins
> -
>
> Key: SLING-5244
> URL: https://issues.apache.org/jira/browse/SLING-5244
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Discovery Impl 1.1.8
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Impl 1.2.2
>
> Attachments:
> VotingHandlerTest.testConcurrentVotesTwoNodes.failure1918.full.txt.gz,
> VotingHandlerTest.testConcurrentVotesTwoNodes.failure1918.txt, loop-i-3.txt
>
>
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1918/testReport/junit/org.apache.sling.discovery.impl.cluster.voting/VotingHandlerTest/testConcurrentVotesTwoNodes/
> {code}
> Error Message
> expected:<456> but was:<455>
> Stacktrace
> java.lang.AssertionError: expected:<456> but was:<455>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.sling.discovery.impl.cluster.voting.VotingHandlerTest.doTestConcurrentVotes(VotingHandlerTest.java:466)
> at
> org.apache.sling.discovery.impl.cluster.voting.VotingHandlerTest.testConcurrentVotesTwoNodes(VotingHandlerTest.java:322)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-4640) Possibility of duplicate leaders w/discovery.impl on eventually consistent repo
[
https://issues.apache.org/jira/browse/SLING-4640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli resolved SLING-4640.
Resolution: Won't Fix
Assignee: Stefan Egli
Marked this as Won't Fix with the following reasons:
* there's rather no standard way of knowing how large the read delay is in any
underlying repository that can be used. That's simply not anything standard.
* if we're talking Oak, then we could come up with a way for Oak to expose such
a delay
** however, exactly for Oak we have discovery.oak which works around
repository-delays in general by using a lower-level collection for storing
group-detection-info (leases). So for discovery.oak SLING-4640 is not relevant.
I don't think it makes sense to come up with yet another non-standard extension
for Oak for something where we have a different solution already..
> Possibility of duplicate leaders w/discovery.impl on eventually consistent
> repo
> ---
>
> Key: SLING-4640
> URL: https://issues.apache.org/jira/browse/SLING-4640
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Discovery Impl 1.1.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> Note: This is a fork of SLING-3432 based on a
> [comment|https://issues.apache.org/jira/browse/SLING-3432?focusedCommentId=14495936=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14495936].
> So here is that comment again:
> Note that [the
> above|https://issues.apache.org/jira/browse/SLING-3432?focusedCommentId=14492494=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14492494]
> does not solve the problem where the underlying repository is eventually
> consistent and the heartbeat configured is too low to catch all possible
> delays (that such an eventually consistent repository might produce under
> load). Consider the following:
> # a cluster consisting of 3 nodes: A, B and C, A is the leader
> # writes from B and C are fast - and can be read by all 3 nodes fast
> # writes from A though are slow (ie A behaves asymmetric: slow writes but
> fast reads)
> # at some point writes from A are slower than the configured heartbeat
> timeout: at this point B and C find out about this and vote on a new
> clusterView consisting only of B and C and (let's say) B becomes leader.
> #* meanwhile at A however: A is still happy: it sees the heartbeats of B and
> C in time and would not start a new voting.
> # at some later point (with a *certain read delay*) A sees that B and C have
> declared a new {{/establishedViews}} - at this point it would (according to
> the new rule above) immediately send a TOPOLOGY_CHANGING and things would be
> 'ok' again.
> #* *but* until it does send this event - *between 4. and 5. - we have two
> leaders: A and B*! -> thus could see issues reported here in SLING-3432 still
> during that small timeframe (which is basically the amount of time it takes
> for the new established view declared by B and C to be read by A).
> #* at a later time, when eg the delays in the repository have come down, A
> would rejoin the cluster - but would have to *not become leader* again, as
> the leader is B and must stay stable.
> This IMHO highlights the problem that using an eventually consistent
> repository (that has no max guaranteed delay) is *not*
> pseudo-network-partition/duplicate-leader free under load.
> Note that what is described here is not fixed by SLING-4627.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5245) discovery.impl.cluster.SingleInstanceTest.testPropertyProviders failed on jenkins
[
https://issues.apache.org/jira/browse/SLING-5245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated SLING-5245:
---
Attachment: SingleInstanceTest.testPropertyProviders.failure1919.full.txt
Attached full [^SingleInstanceTest.testPropertyProviders.failure1919.full.txt]
which shows that this is also a duplicate of SLING-5243:
{code}
02.11.2015 16:57:36.160 *INFO * [VotingEventListener-standaloneInstance]
7d336f55-5204-4015-9205-1a1f76f3d42b: analyzeVotings: vote doesnt match my live
view, voting no. comparison result: no mem
bers resource found, vote: a
VotingView[viewId=ae2873bc-acdf-4fdf-bad7-eef234df4a68,
id=ae2873bc-acdf-4fdf-bad7-eef234df4a68, initiator=null, members=]
{code}
> discovery.impl.cluster.SingleInstanceTest.testPropertyProviders failed on
> jenkins
> -
>
> Key: SLING-5245
> URL: https://issues.apache.org/jira/browse/SLING-5245
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Discovery Impl 1.2.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Impl 1.2.2
>
> Attachments:
> SingleInstanceTest.testPropertyProviders.failure1919.full.txt,
> SingleInstanceTest.testPropertyProviders.failure1919.txt
>
>
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1919/testReport/junit/org.apache.sling.discovery.impl.cluster/SingleInstanceTest/testPropertyProviders/
> {code}
> Error Message
> no established view at the moment
> Stacktrace
> org.apache.sling.discovery.base.commons.UndefinedClusterViewException: no
> established view at the moment
> at
> org.apache.sling.discovery.impl.cluster.ClusterViewServiceImpl.getLocalClusterView(ClusterViewServiceImpl.java:102)
> at
> org.apache.sling.discovery.base.its.AbstractSingleInstanceTest.testPropertyProviders(AbstractSingleInstanceTest.java:143)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5014) Uninstall directive in provisioning model might just lead to downgrade of bundle
[ https://issues.apache.org/jira/browse/SLING-5014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominik Süß updated SLING-5014: --- Attachment: SLING-5014-1.diff [~bdelacretaz], [~cziegeler] the last days I created a patch for the installer core and added a new bundle that implement a blacklist feature for the installer. The current bootstrap method just leads to uninstallation of a bundle but as soon as further (non-uninstalled) candidates than the uninstalled ones exist in the system the installer will install those. And even if this behavior would be fixed nothing would prevent a user from accidentially triggering a new installation by installing some obsolete Package containing such an installable. The default blacklist implementation therefore by default takes the uninstall commands from the sling_bootstrap.txt and prevents any installation (via installer) of the defined bundles (respecting version ranges). It is also possible to define further rules via osgi config. The blacklist implementation does also take care of uninstallation and downgrades and therefore eliminate issues with obsolete bundles hanging around in the system and therefore preventing a clean uninstallation of bundles without the need to do further housekeeping in the repository and/or filesystem. > Uninstall directive in provisioning model might just lead to downgrade of > bundle > > > Key: SLING-5014 > URL: https://issues.apache.org/jira/browse/SLING-5014 > Project: Sling > Issue Type: Bug > Components: Installer >Affects Versions: Installer Core 3.6.6 >Reporter: Dominik Süß > Attachments: SLING-5014-1.diff > > > In case a bundle has mutliple install candiates only the highest version > (with the highest priorty for the same versions) wins. An uninstall directive > uninstalls this version. The way the OSGi install behavior is defined this > lets the next artifact in the priority queue to get active and consequently > only leads to downgrade to the next in the queue. > As the uninstall directive declares a range that should be uninstalled the > expectation is that after a startup with such an uninstall directive none of > the delcared versions are in an installed state. In consequence the OSGi > installer must save this metainformation in the state that prevents a > downgrade to a version that is part of an active uninstall directive. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (SLING-5236) Remove loginAdministrative() usage from sightly Components
[
https://issues.apache.org/jira/browse/SLING-5236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu reassigned SLING-5236:
---
Assignee: Radu Cotescu
> Remove loginAdministrative() usage from sightly Components
> --
>
> Key: SLING-5236
> URL: https://issues.apache.org/jira/browse/SLING-5236
> Project: Sling
> Issue Type: Improvement
> Components: Scripting
>Reporter: Antonio Sanso
>Assignee: Radu Cotescu
>
> * {{org.apache.sling.scripting.core}}: 2
> * {{org.apache.sling.scripting.sightly}}: 3
> * {{org.apache.sling.scripting.sightly.js.provider}}: 2
> total of 7 occurrences
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-5252) Remove getAdministrativeResourceResolver() from Scripting Core
Radu Cotescu created SLING-5252:
---
Summary: Remove getAdministrativeResourceResolver() from Scripting
Core
Key: SLING-5252
URL: https://issues.apache.org/jira/browse/SLING-5252
Project: Sling
Issue Type: Sub-task
Components: Scripting
Affects Versions: Scripting Core 2.0.34
Reporter: Radu Cotescu
Fix For: Scripting Core 2.0.36
2 occurrences in {{org.apache.sling.scripting.core.impl.ScriptCacheImpl}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5254) Remove getAdministrativeResourceResolver() from the Sightly JS Provider
[
https://issues.apache.org/jira/browse/SLING-5254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-5254:
Affects Version/s: (was: Scripting Sightly Engine 1.0.6)
Scripting Sightly JS Use Provider 1.0.10
> Remove getAdministrativeResourceResolver() from the Sightly JS Provider
> ---
>
> Key: SLING-5254
> URL: https://issues.apache.org/jira/browse/SLING-5254
> Project: Sling
> Issue Type: Sub-task
> Components: Scripting
>Affects Versions: Scripting Sightly JS Use Provider 1.0.10
>Reporter: Radu Cotescu
> Fix For: Sightly JS Use Provider 1.0.12
>
>
> 1 occurrences in
> {{org.apache.sling.scripting.sightly.js.impl.jsapi.SlyBindingsValuesProvider}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-5254) Remove getAdministrativeResourceResolver() from the Sightly JS Provider
Radu Cotescu created SLING-5254:
---
Summary: Remove getAdministrativeResourceResolver() from the
Sightly JS Provider
Key: SLING-5254
URL: https://issues.apache.org/jira/browse/SLING-5254
Project: Sling
Issue Type: Sub-task
Components: Scripting
Affects Versions: Scripting Sightly Engine 1.0.6
Reporter: Radu Cotescu
Fix For: Scripting Sightly Engine 1.0.8
3 occurrences in
{{org.apache.sling.scripting.sightly.impl.compiler.UnitChangeMonitor}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-5253) Remove getAdministrativeResourceResolver() from the Sightly engine
Radu Cotescu created SLING-5253:
---
Summary: Remove getAdministrativeResourceResolver() from the
Sightly engine
Key: SLING-5253
URL: https://issues.apache.org/jira/browse/SLING-5253
Project: Sling
Issue Type: Sub-task
Components: Scripting
Affects Versions: Scripting Core 2.0.34
Reporter: Radu Cotescu
Fix For: Scripting Core 2.0.36
2 occurrences in {{org.apache.sling.scripting.core.impl.ScriptCacheImpl}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5254) Remove getAdministrativeResourceResolver() from the Sightly JS Provider
[
https://issues.apache.org/jira/browse/SLING-5254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-5254:
Description: 1 occurrences in
{{org.apache.sling.scripting.sightly.js.impl.jsapi.SlyBindingsValuesProvider}}.
(was: 3 occurrences in
{{org.apache.sling.scripting.sightly.impl.compiler.UnitChangeMonitor}}.)
> Remove getAdministrativeResourceResolver() from the Sightly JS Provider
> ---
>
> Key: SLING-5254
> URL: https://issues.apache.org/jira/browse/SLING-5254
> Project: Sling
> Issue Type: Sub-task
> Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.6
>Reporter: Radu Cotescu
> Fix For: Scripting Sightly Engine 1.0.8
>
>
> 1 occurrences in
> {{org.apache.sling.scripting.sightly.js.impl.jsapi.SlyBindingsValuesProvider}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5236) Remove loginAdministrative() usage from sightly Components
[
https://issues.apache.org/jira/browse/SLING-5236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-5236:
Summary: Remove loginAdministrative() usage from sightly Components (was:
Remove loginAdministrative() usage from sightly Compontents)
> Remove loginAdministrative() usage from sightly Components
> --
>
> Key: SLING-5236
> URL: https://issues.apache.org/jira/browse/SLING-5236
> Project: Sling
> Issue Type: Improvement
> Components: Scripting
>Reporter: Antonio Sanso
>
> * {{org.apache.sling.scripting.core}}: 2
> * {{org.apache.sling.scripting.sightly}}: 3
> * {{org.apache.sling.scripting.sightly.js.provider}}: 2
> total of 7 occurrences
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5236) Remove getAdministrativeResourceResolver() usage from scripting bundles
[
https://issues.apache.org/jira/browse/SLING-5236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-5236:
Summary: Remove getAdministrativeResourceResolver() usage from scripting
bundles (was: Remove loginAdministrative() usage from sightly Components)
> Remove getAdministrativeResourceResolver() usage from scripting bundles
> ---
>
> Key: SLING-5236
> URL: https://issues.apache.org/jira/browse/SLING-5236
> Project: Sling
> Issue Type: Improvement
> Components: Scripting
>Reporter: Antonio Sanso
>Assignee: Radu Cotescu
>
> * {{org.apache.sling.scripting.core}}: 2
> * {{org.apache.sling.scripting.sightly}}: 3
> * {{org.apache.sling.scripting.sightly.js.provider}}: 2
> total of 7 occurrences
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5253) Remove getAdministrativeResourceResolver() from the Sightly engine
[
https://issues.apache.org/jira/browse/SLING-5253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-5253:
Affects Version/s: (was: Scripting Core 2.0.34)
Scripting Sightly Engine 1.0.6
> Remove getAdministrativeResourceResolver() from the Sightly engine
> --
>
> Key: SLING-5253
> URL: https://issues.apache.org/jira/browse/SLING-5253
> Project: Sling
> Issue Type: Sub-task
> Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.6
>Reporter: Radu Cotescu
> Fix For: Scripting Sightly Engine 1.0.8
>
>
> 3 occurrences in
> {{org.apache.sling.scripting.sightly.impl.compiler.UnitChangeMonitor}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5253) Remove getAdministrativeResourceResolver() from the Sightly engine
[
https://issues.apache.org/jira/browse/SLING-5253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-5253:
Description: 3 occurrences in
{{org.apache.sling.scripting.sightly.impl.compiler.UnitChangeMonitor}}. (was:
2 occurrences in {{org.apache.sling.scripting.core.impl.ScriptCacheImpl}}.)
> Remove getAdministrativeResourceResolver() from the Sightly engine
> --
>
> Key: SLING-5253
> URL: https://issues.apache.org/jira/browse/SLING-5253
> Project: Sling
> Issue Type: Sub-task
> Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.6
>Reporter: Radu Cotescu
> Fix For: Scripting Sightly Engine 1.0.8
>
>
> 3 occurrences in
> {{org.apache.sling.scripting.sightly.impl.compiler.UnitChangeMonitor}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5254) Remove getAdministrativeResourceResolver() from the Sightly JS Provider
[
https://issues.apache.org/jira/browse/SLING-5254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-5254:
Fix Version/s: (was: Scripting Sightly Engine 1.0.8)
Sightly JS Use Provider 1.0.12
> Remove getAdministrativeResourceResolver() from the Sightly JS Provider
> ---
>
> Key: SLING-5254
> URL: https://issues.apache.org/jira/browse/SLING-5254
> Project: Sling
> Issue Type: Sub-task
> Components: Scripting
>Affects Versions: Scripting Sightly JS Use Provider 1.0.10
>Reporter: Radu Cotescu
> Fix For: Sightly JS Use Provider 1.0.12
>
>
> 1 occurrences in
> {{org.apache.sling.scripting.sightly.js.impl.jsapi.SlyBindingsValuesProvider}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5254) Remove getAdministrativeResourceResolver() from the Sightly JS Provider
[
https://issues.apache.org/jira/browse/SLING-5254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-5254:
Description: 1 occurrence in
{{org.apache.sling.scripting.sightly.js.impl.jsapi.SlyBindingsValuesProvider}}.
(was: 1 occurrences in
{{org.apache.sling.scripting.sightly.js.impl.jsapi.SlyBindingsValuesProvider}}.)
> Remove getAdministrativeResourceResolver() from the Sightly JS Provider
> ---
>
> Key: SLING-5254
> URL: https://issues.apache.org/jira/browse/SLING-5254
> Project: Sling
> Issue Type: Sub-task
> Components: Scripting
>Affects Versions: Scripting Sightly JS Use Provider 1.0.10
>Reporter: Radu Cotescu
> Fix For: Sightly JS Use Provider 1.0.12
>
>
> 1 occurrence in
> {{org.apache.sling.scripting.sightly.js.impl.jsapi.SlyBindingsValuesProvider}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5234) Remove loginAdministrative() usage from org.apache.sling.xss
[ https://issues.apache.org/jira/browse/SLING-5234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-5234: Fix Version/s: XSS Protection API 1.0.8 > Remove loginAdministrative() usage from org.apache.sling.xss > > > Key: SLING-5234 > URL: https://issues.apache.org/jira/browse/SLING-5234 > Project: Sling > Issue Type: Improvement > Components: Extensions >Affects Versions: XSS Protection API 1.0.6 >Reporter: Antonio Sanso > Fix For: XSS Protection API 1.0.8 > > > counted 1 occurrence -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5234) Remove loginAdministrative() usage from org.apache.sling.xss
[ https://issues.apache.org/jira/browse/SLING-5234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-5234: Affects Version/s: (was: XSS Protection API 1.0.0) XSS Protection API 1.0.6 > Remove loginAdministrative() usage from org.apache.sling.xss > > > Key: SLING-5234 > URL: https://issues.apache.org/jira/browse/SLING-5234 > Project: Sling > Issue Type: Improvement > Components: Extensions >Affects Versions: XSS Protection API 1.0.6 >Reporter: Antonio Sanso > Fix For: XSS Protection API 1.0.8 > > > counted 1 occurrence -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5234) Remove loginAdministrative() usage from org.apache.sling.xss
[ https://issues.apache.org/jira/browse/SLING-5234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-5234: Affects Version/s: XSS Protection API 1.0.0 > Remove loginAdministrative() usage from org.apache.sling.xss > > > Key: SLING-5234 > URL: https://issues.apache.org/jira/browse/SLING-5234 > Project: Sling > Issue Type: Improvement > Components: Extensions >Affects Versions: XSS Protection API 1.0.6 >Reporter: Antonio Sanso > Fix For: XSS Protection API 1.0.8 > > > counted 1 occurrence -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (SLING-5234) Remove loginAdministrative() usage from org.apache.sling.xss
[ https://issues.apache.org/jira/browse/SLING-5234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu reassigned SLING-5234: --- Assignee: Radu Cotescu > Remove loginAdministrative() usage from org.apache.sling.xss > > > Key: SLING-5234 > URL: https://issues.apache.org/jira/browse/SLING-5234 > Project: Sling > Issue Type: Improvement > Components: Extensions >Affects Versions: XSS Protection API 1.0.6 >Reporter: Antonio Sanso >Assignee: Radu Cotescu > Fix For: XSS Protection API 1.0.8 > > > counted 1 occurrence -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5246) discovery.impl.cluster.SingleInstanceTest.testTopologyEventListeners failed on jenkins
[
https://issues.apache.org/jira/browse/SLING-5246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated SLING-5246:
---
Attachment:
SingleInstanceTest.testTopologyEventListeners.failure1919.full.txt
Attached full
[^SingleInstanceTest.testTopologyEventListeners.failure1919.full.txt] which
shows that this is a duplicate of SLING-5243:
{code}
02.11.2015 16:57:31.410 *INFO * [VotingEventListener-standaloneInstance]
e3caa2a9-d7fb-40d2-896b-f8846175f45f: analyzeVotings: vote doesnt match my live
view, voting no. comparison result: no mem
bers resource found, vote: a
VotingView[viewId=8e2551a6-c6af-40c0-81e4-fadc8f381c28,
id=8e2551a6-c6af-40c0-81e4-fadc8f381c28, initiator=null, members=]
{code}
> discovery.impl.cluster.SingleInstanceTest.testTopologyEventListeners failed
> on jenkins
> --
>
> Key: SLING-5246
> URL: https://issues.apache.org/jira/browse/SLING-5246
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Discovery Impl 1.2.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Impl 1.2.2
>
> Attachments:
> SingleInstanceTest.testTopologyEventListeners.failure1919.full.txt,
> SingleInstanceTest.testTopologyEventListeners.failure1919.txt
>
>
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1919/testReport/junit/org.apache.sling.discovery.impl.cluster/SingleInstanceTest/testTopologyEventListeners/
> {code}
> Error Message
> expected:<0> but was:<1>
> Stacktrace
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.sling.discovery.base.its.AbstractSingleInstanceTest.testTopologyEventListeners(AbstractSingleInstanceTest.java:206)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-5246) discovery.impl.cluster.SingleInstanceTest.testTopologyEventListeners failed on jenkins
[
https://issues.apache.org/jira/browse/SLING-5246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli resolved SLING-5246.
Resolution: Duplicate
> discovery.impl.cluster.SingleInstanceTest.testTopologyEventListeners failed
> on jenkins
> --
>
> Key: SLING-5246
> URL: https://issues.apache.org/jira/browse/SLING-5246
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Discovery Impl 1.2.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Impl 1.2.2
>
> Attachments:
> SingleInstanceTest.testTopologyEventListeners.failure1919.full.txt,
> SingleInstanceTest.testTopologyEventListeners.failure1919.txt
>
>
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1919/testReport/junit/org.apache.sling.discovery.impl.cluster/SingleInstanceTest/testTopologyEventListeners/
> {code}
> Error Message
> expected:<0> but was:<1>
> Stacktrace
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.sling.discovery.base.its.AbstractSingleInstanceTest.testTopologyEventListeners(AbstractSingleInstanceTest.java:206)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5244) discovery.impl.cluster.voting.VotingHandlerTest.testConcurrentVotesTwoNodes failed on jenkins
[
https://issues.apache.org/jira/browse/SLING-5244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated SLING-5244:
---
Attachment:
VotingHandlerTest.testConcurrentVotesTwoNodes.failure1918.full.txt.gz
Attached full
[^VotingHandlerTest.testConcurrentVotesTwoNodes.failure1918.full.txt.gz]
> discovery.impl.cluster.voting.VotingHandlerTest.testConcurrentVotesTwoNodes
> failed on jenkins
> -
>
> Key: SLING-5244
> URL: https://issues.apache.org/jira/browse/SLING-5244
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Discovery Impl 1.1.8
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Impl 1.2.2
>
> Attachments:
> VotingHandlerTest.testConcurrentVotesTwoNodes.failure1918.full.txt.gz,
> VotingHandlerTest.testConcurrentVotesTwoNodes.failure1918.txt
>
>
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1918/testReport/junit/org.apache.sling.discovery.impl.cluster.voting/VotingHandlerTest/testConcurrentVotesTwoNodes/
> {code}
> Error Message
> expected:<456> but was:<455>
> Stacktrace
> java.lang.AssertionError: expected:<456> but was:<455>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.sling.discovery.impl.cluster.voting.VotingHandlerTest.doTestConcurrentVotes(VotingHandlerTest.java:466)
> at
> org.apache.sling.discovery.impl.cluster.voting.VotingHandlerTest.testConcurrentVotesTwoNodes(VotingHandlerTest.java:322)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5244) discovery.impl.cluster.voting.VotingHandlerTest.testConcurrentVotesTwoNodes failed on jenkins
[
https://issues.apache.org/jira/browse/SLING-5244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated SLING-5244:
---
Attachment: loop-i-3.txt
Attached [^loop-i-3.txt] which is an extraction of the full.txt just showing
the loop with {{i=3}}. The findings:
* unlike *all* other votings, this one concludes in just one 'j-loop' - that
is, it requires just once doing {{analyzeVotings}} by both instances
* this is possible when the slingId1 created voting1, slingId2 creates voting2,
then slingId2 votes first, votes yes for voting1 cos that's the lower order
(alphabetic order), then slingId1 comes to analyze and sees that its voting
already won. Actually not really an unrealistic scenario, but seems it happens
rarely and usually 2 rounds of analyzeVotings are necessary (probably cos they
don't *see* the peers vote yet cos they are really voting concurrently)
* when there's only 1 'j-loop', then there's only 1 no-vote - which is exactly
the missing one in the end
* the 'i-loop' checks for at least getting one no-vote less than number of
votees, and that assumption should always hold - however we cannot make any
assertions in the end anymore easily
> discovery.impl.cluster.voting.VotingHandlerTest.testConcurrentVotesTwoNodes
> failed on jenkins
> -
>
> Key: SLING-5244
> URL: https://issues.apache.org/jira/browse/SLING-5244
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Discovery Impl 1.1.8
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Impl 1.2.2
>
> Attachments:
> VotingHandlerTest.testConcurrentVotesTwoNodes.failure1918.full.txt.gz,
> VotingHandlerTest.testConcurrentVotesTwoNodes.failure1918.txt, loop-i-3.txt
>
>
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1918/testReport/junit/org.apache.sling.discovery.impl.cluster.voting/VotingHandlerTest/testConcurrentVotesTwoNodes/
> {code}
> Error Message
> expected:<456> but was:<455>
> Stacktrace
> java.lang.AssertionError: expected:<456> but was:<455>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.sling.discovery.impl.cluster.voting.VotingHandlerTest.doTestConcurrentVotes(VotingHandlerTest.java:466)
> at
> org.apache.sling.discovery.impl.cluster.voting.VotingHandlerTest.testConcurrentVotesTwoNodes(VotingHandlerTest.java:322)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-5245) discovery.impl.cluster.SingleInstanceTest.testPropertyProviders failed on jenkins
[
https://issues.apache.org/jira/browse/SLING-5245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli resolved SLING-5245.
Resolution: Duplicate
Same as SLING-5246, SLING-5245 is also a duplicate of SLING-5243
> discovery.impl.cluster.SingleInstanceTest.testPropertyProviders failed on
> jenkins
> -
>
> Key: SLING-5245
> URL: https://issues.apache.org/jira/browse/SLING-5245
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Discovery Impl 1.2.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Impl 1.2.2
>
> Attachments:
> SingleInstanceTest.testPropertyProviders.failure1919.full.txt,
> SingleInstanceTest.testPropertyProviders.failure1919.txt
>
>
> https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.discovery.impl/1919/testReport/junit/org.apache.sling.discovery.impl.cluster/SingleInstanceTest/testPropertyProviders/
> {code}
> Error Message
> no established view at the moment
> Stacktrace
> org.apache.sling.discovery.base.commons.UndefinedClusterViewException: no
> established view at the moment
> at
> org.apache.sling.discovery.impl.cluster.ClusterViewServiceImpl.getLocalClusterView(ClusterViewServiceImpl.java:102)
> at
> org.apache.sling.discovery.base.its.AbstractSingleInstanceTest.testPropertyProviders(AbstractSingleInstanceTest.java:143)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (SLING-4380) Use sling mocks for the discovery impl tests
[ https://issues.apache.org/jira/browse/SLING-4380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli reassigned SLING-4380: -- Assignee: Stefan Egli > Use sling mocks for the discovery impl tests > > > Key: SLING-4380 > URL: https://issues.apache.org/jira/browse/SLING-4380 > Project: Sling > Issue Type: Improvement > Components: Extensions, Testing >Affects Versions: Discovery Impl 1.0.12 >Reporter: Robert Munteanu >Assignee: Stefan Egli > Fix For: Discovery Impl 1.2.2 > > > The org.apache.sling.discovery.impl has its own utility mocks in > https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/discovery/impl/src/test/java/org/apache/sling/discovery/impl/setup/ > . Most of these can be replaced by the new Sling mocks. > The benefits would be: > - less maintenance for the discovery impl project > - more exposure/coverage for the Sling mocks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5253) Remove getAdministrativeResourceResolver() from the Sightly engine
[
https://issues.apache.org/jira/browse/SLING-5253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-5253:
Fix Version/s: (was: Scripting Core 2.0.36)
Scripting Sightly Engine 1.0.8
> Remove getAdministrativeResourceResolver() from the Sightly engine
> --
>
> Key: SLING-5253
> URL: https://issues.apache.org/jira/browse/SLING-5253
> Project: Sling
> Issue Type: Sub-task
> Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.6
>Reporter: Radu Cotescu
> Fix For: Scripting Sightly Engine 1.0.8
>
>
> 3 occurrences in
> {{org.apache.sling.scripting.sightly.impl.compiler.UnitChangeMonitor}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
