[jira] [Commented] (SLING-5263) Request to implement junit test cases for LogSupport.java

[Tien Nguyen Viet (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14991308#comment-14991308
 ] 

Tien Nguyen Viet commented on SLING-5263:
-

Hi [~asanso]

Can you approve my request ? if yes please assign the task to me.

> Request to implement junit test cases for LogSupport.java
> -
>
> Key: SLING-5263
> URL: https://issues.apache.org/jira/browse/SLING-5263
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Tien Nguyen Viet
>Priority: Trivial
>
> org.apache.sling.commons.logservice.internal.LogSupport.java is not 100% 
> covered by junit test cases, can i request to let me implement the test cases 
> ?
> CC: [~cziegeler]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Removing loginAdministrative, how to test that, and service username conventions

[Bertrand Delacretaz]

On Thu, Nov 5, 2015 at 9:48 AM, Carsten Ziegeler  wrote:
> ...Keeping it separate from the beginning is the clearest way and works in
> all cases...

I agree as long as that separation does not complicate things more
than strictly needed - provisioning model sounds good, whereas having
to create extra bundles is a hassle.

-Bertrand

Re: [RT] Handling resource (provider) changes

[Carsten Ziegeler]

Am 04.11.15 um 19:27 schrieb Robert Munteanu:
> On Wed, 2015-11-04 at 18:45 +0100, Carsten Ziegeler wrote:
>> The current active model for observation event for resources through
>> OSGi events is modelled after JCR observation which means that for
>> changes to a tree you might only get an event for the root of that
>> tree.
>> Especially when a whole tree is deleted, you get a single event.
>> I assume, the same could in theory be true for adding.
> 
> Just to make sure I understand correctly:
> 
> - when a tree at /foo is deleted we get a single event which says that
> the node at /foo is deleted, but we do not know which children were
> removed - we only get a single path

Correct.

> - when a tree at /bar is added, we get a single event but we get all
> the date about the resources under /bar, e.g. /bar/one/two/three

I think this depends :) Afaik, right now for adds we get an event for
every resource, but this is not necessarily guaranteed by JCR
observation (at least that's what people told me).
> 
> Is that correct?
> 
>> The question is, whether we want to keep this model for the
>> observation
>> API we're about to implement. Especially as there are some additional
>> things to consider:
>>
>> 1. With Oak we could register observation listener which provide the
>> information about every node removed/added/changed. So we can send
>> out
>> detailed events. Other resource provider implementations could simply
>> follow that concept.
>>  
>> 2. We have three events for resources: added/removed/changed but also
>> two events for resource providers. Obviously, if a resource provider
>> is
>> mounted at some path and is unregistered, the whole tree is removed.
>> Again, we just send out a single event.
>>
>> For 2. we definitely don't want to send out an event for every
>> resource
>> of that provider as that would be way too expensive.
>>
>> For 1. we might start sending out too many events as well and I
>> assume
>> code is already prepared for that case.
>>
>> I think we should keep the optimization (and make this clear in the
>> new
>> observation API) 
> 
> +1
> 
>> and we probably should collapse the two special
>> resource provider events into resource events: instead of sending out
>> a
>> resource provider added/removed, we send out a resource
>> added/removed.
>> Listeners right now usually handle all five events, and we could
>> reduce
>> this to three events, making everything compacter, nicer and easier
>> to
>> understand.
> 
> I think simplifying the listeners is good, but I wonder whether anyone
> actually listens to the resource provider added/removed events. Perhaps
> we can have a separate listener for those?

Every implementation doing caching (e.g. jsp scripting) listens to those
events. That's a must, otherwise you end up caching something from a
provider which disappeared after you cached it. My initial idea was to
have a separate interface, but as the usual pattern is to listen to both
anyway, I think we can just fold the events in and make everything easier

Regards
Carsten

> 
> Robert
> 


-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: Removing loginAdministrative, how to test that, and service username conventions

[Carsten Ziegeler]

Am 04.11.15 um 19:17 schrieb Robert Munteanu:
> On Wed, 2015-11-04 at 18:51 +0100, Carsten Ziegeler wrote:
>> Am 04.11.15 um 17:26 schrieb Bertrand Delacretaz:
>>> On Wed, Nov 4, 2015 at 5:22 PM, Bertrand Delacretaz
>>>  wrote:
 ...Antonio recently created a bunch of "Remove
 loginAdministrative()
 usage" tickets for several of our components (SLING-5227 for
 example)
>>>
>>> This also means backward compatibility issues, as the modified
>>> modules
>>> will require the corresponding service users to exist.
>>>
>>> We probably need a super simple mechanism for creating those users
>>> -
>>> maybe embed their definitions in the corresponding bundles, and let
>>> an
>>> (optional) bundle process them.
>>>
>>
>> No, the user and also the ACL must not be part of the bundle - it is
>> not
>> the concern of the implementation to create the user and setup the
>> ACLs.
>> We must not mix these things.
>> And this is also fragile, bringing in yet another mechanism to do
>> something does not make our system more stable. We already have most
>> pieces in place for provisioning: the OSGi installer and friends.
>> For installing content, and users and ACLs are content, we have the
>> JCR
>> contentloader.
>>
>> I suggest we create for each feature a separate bundle with the user
>> definition and the ACLs. The stuff gets then installed - like any
>> other
>> content - through the contentloader.
> 
> A brief look at the jcr.contentloader bundle leads me to believe that
> we do not have support for installing users and ACLs, and must add it
> instead.
> 
Ok, but that shouldn't be too hard and is imho the better approach
compared to add yet another bundle listening for bundles and doing
something.
We also must be very clear and what happens when such bundle gets
uninstalled, no matter which approach we take.

But my main point is: let's not mix concerns just because its easy for
the developer.

Now another option is to do some additional handling in the provisioning
model, so instead of creating an artificial bundle, we could support
having a "free" text section in the provisioning model which then gets
processed in some way. I think, this would be the easiest way: you
define the service user, security configuration (which is already part
of the provisioning model) and ACLs as part of the provisioning model.
That's super easy, user friendly and we just need to find a way to get
this interpreted. Easiest way, the tooling creates a bundle :) which
then gets picked up by the jcr contentloader.
I personally would prefer having everything in the provisioning model
instead of "hiding" it in bundles - no matter how it really ends up in
the runtime.

Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Created] (SLING-5265) Rethink the current api

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-5265:
---

 Summary: Rethink the current api
 Key: SLING-5265
 URL: https://issues.apache.org/jira/browse/SLING-5265
 Project: Sling
  Issue Type: Sub-task
  Components: API, JCR, ResourceResolver
Reporter: Carsten Ziegeler
 Fix For: JCR Resource 2.6.0, API 2.10.0, Resource Resolver 1.3.0


I've started different threads in the dev list, whether the current api is good 
or could be changed. The three main points are:
- how to deal with external events
- should we add pattern/globbing support for listeners
- should we merge the resource provider events into the resource events

We should update this issue based on the results of the discussions



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5263) Request to implement junit test cases for LogSupport.java

[Antonio Sanso (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14991293#comment-14991293
 ] 

Antonio Sanso commented on SLING-5263:
--

as rule of thumbs contribution are always more than welcome :)

> Request to implement junit test cases for LogSupport.java
> -
>
> Key: SLING-5263
> URL: https://issues.apache.org/jira/browse/SLING-5263
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Tien
>Priority: Trivial
>
> org.apache.sling.commons.logservice.internal.LogSupport.java is not 100% 
> covered by junit test cases, can i request to let me implement the test cases 
> ?
> CC: [~cziegeler]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-5264) DiscoveryServiceImplTest.testThirtyInstances failed on jenkins

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli resolved SLING-5264.

Resolution: Fixed

Increased timeouts to account for slowness of apache jenkins in rev 1712724

> DiscoveryServiceImplTest.testThirtyInstances failed on jenkins
> --
>
> Key: SLING-5264
> URL: https://issues.apache.org/jira/browse/SLING-5264
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Impl 1.2.0, Discovery Base 1.0.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Minor
> Fix For: Discovery Impl 1.2.2, Discovery Base 1.0.4
>
> Attachments: testThirtyInstances.txt.gz
>
>
> DiscoveryServiceImplTest.testThirtyInstances failed on jenkins: 
> https://builds.apache.org/job/sling-trunk-1.7/2659/
> {code}
> DiscoveryServiceImplTest>AbstractDiscoveryServiceTest.testThirtyInstances:304->AbstractDiscoveryServiceTest.startRetryLoop:311->AbstractDiscoveryServiceTest.startRetryLoop:315
>  RetryLoop failed, condition is false after 100 seconds: null
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-5263) Request to implement junit test cases for LogSupport.java

[Tien (JIRA)]

Tien created SLING-5263:
---

 Summary: Request to implement junit test cases for LogSupport.java
 Key: SLING-5263
 URL: https://issues.apache.org/jira/browse/SLING-5263
 Project: Sling
  Issue Type: Improvement
  Components: Commons
Reporter: Tien
Priority: Trivial


org.apache.sling.commons.logservice.internal.LogSupport.java is not 100% 
covered by junit test cases, can i request to let me implement the test cases ?

CC: [~cziegeler]




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Removing loginAdministrative, how to test that, and service username conventions

[Carsten Ziegeler]

Am 05.11.15 um 09:41 schrieb Bertrand Delacretaz:
> On Thu, Nov 5, 2015 at 9:35 AM, Carsten Ziegeler  wrote:
>> ...I personally would prefer having everything in the provisioning model
>> instead of "hiding" it in bundles - no matter how it really ends up in
>> the runtime...
> 
> That would work but for testing I think we also need a utility to
> process such provisioning models at runtime. For example when testing
> outside of the OSGi environment, just with a SlingRepository.
> 
Sure, we can put the code processing the model in a common module and
use it from various places.

Regards
Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: Removing loginAdministrative, how to test that, and service username conventions

[Bertrand Delacretaz]

On Thu, Nov 5, 2015 at 9:35 AM, Carsten Ziegeler  wrote:
> ...I personally would prefer having everything in the provisioning model
> instead of "hiding" it in bundles - no matter how it really ends up in
> the runtime...

That would work but for testing I think we also need a utility to
process such provisioning models at runtime. For example when testing
outside of the OSGi environment, just with a SlingRepository.

-Bertrand

[jira] [Created] (SLING-5264) DiscoveryServiceImplTest.testThirtyInstances failed on jenkins

[Stefan Egli (JIRA)]

Stefan Egli created SLING-5264:
--

 Summary: DiscoveryServiceImplTest.testThirtyInstances failed on 
jenkins
 Key: SLING-5264
 URL: https://issues.apache.org/jira/browse/SLING-5264
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Discovery Impl 1.2.0, Discovery Base 1.0.2
Reporter: Stefan Egli
Assignee: Stefan Egli
Priority: Minor
 Fix For: Discovery Impl 1.2.2, Discovery Base 1.0.4


DiscoveryServiceImplTest.testThirtyInstances failed on jenkins: 

https://builds.apache.org/job/sling-trunk-1.7/2659/
{code}
DiscoveryServiceImplTest>AbstractDiscoveryServiceTest.testThirtyInstances:304->AbstractDiscoveryServiceTest.startRetryLoop:311->AbstractDiscoveryServiceTest.startRetryLoop:315
 RetryLoop failed, condition is false after 100 seconds: null
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Sling Testing OSGi Mock 1.7.0

[Carsten Ziegeler]

+1
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: Removing loginAdministrative, how to test that, and service username conventions

[Carsten Ziegeler]

Am 05.11.15 um 09:39 schrieb Bertrand Delacretaz:
> Hi,
> 
> On Wed, Nov 4, 2015 at 6:51 PM, Carsten Ziegeler  wrote:
>> ...I suggest we create for each feature a separate bundle with the user
>> definition and the ACLs. The stuff gets then installed - like any other
>> content - through the contentloader
> 
> So taking SLING-5227 as an example (the contrib/bgservlets module) you
> suggest (option A) creating a companion bgservlets-users bundle that
> provides the user/ACL definitions?
> 
> That would work, but I think my suggestion (option B) is simpler:
> include those default definitions in the main bundle, but by default
> to not install the service that processes them.
> 
> So by default no users/ACLs are created, and if you want backwards
> compatibility or for testing purposes you just install a single bundle
> that processes those embedded definitions.
> 
> This means those definitions need to use a different mechanism than
> our current contentloader (or maybe a new plugin for that
> contentloader) but that's not hard to implement.
> 

My main point is: how does the developer of the bgservlets know which
user to use? Which ACLs to apply? There could be a configuration which
changes the default location of the bgservlets stuff in the repository
to a different path. (Maybe this is not possible with the bgservlets,
but it is definitely true for other bundles). Therefore the developer of
the bundle has zero clue and he should not have it. This might be
different on every installation.

If we put this as a default setting which is not processed in the
bundle, assume you have two bundles with such content. You want to have
the defaults of one of them but not the other - how do you handle this?
That can be dealt with of course, but it adds then another thing on top
and makes it much more complicated than it should be.
Keeping it separate from the beginning is the clearest way and works in
all cases.

Carsten


-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Updated] (SLING-5264) DiscoveryServiceImplTest.testThirtyInstances failed on jenkins

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli updated SLING-5264:
---
Attachment: testThirtyInstances.txt.gz

Attached [^testThirtyInstances.txt.gz] which shows that what happens is that 
when 30 instances are busy voting, that it takes already quite a long time 
(46sec) until all the votes come in (as there are many competing votes), but 
also that the promotion takes long (14sec) - which is just what is configured 
as heartbeatTimeout: 60sec. So that's just too short for running this test on 
jenkins it seems.

{code}
04.11.2015 23:42:50.628 *INFO * [Test-ViewCheckerRunner [i21]] VotingView: 
newVoting: new voting started: newViewId=1d07b39a-f5b3-4e14-bf3e-a09b0d2e8c6e, 
initiatorId=fe69e98e-38b1-42fa-aa37-fb16dd71d8c5, resource=MockedResource, 
type=nt:unstructured, 
path=/var/discovery/testing/ongoingVotings/1d07b39a-f5b3-4e14-bf3e-a09b0d2e8c6e,
 #members: 30, members: [b32c362d-a3b0-46de-b917-98750884819e, 
6c07306f-a92e-455e-a962-cbc9c62af88a, bcbf490c-936d-487b-b81f-fac36b20237a, 
7047ae33-2dd4-43d1-a761-3d688d5e3d47, c81bf19a-fbf8-4605-a7b7-3d160229f2e2, 
67caf350-0669-4d36-98ce-a1fcdd5bf173, 4c0efefc-94c9-444d-9929-97ea80360e93, 
6d7a6243-5157-44aa-b8d8-99fb50a1f09b, fe69e98e-38b1-42fa-aa37-fb16dd71d8c5, 
b33239d5-40cd-41f7-ae2a-e43d49d6135d, 102b4486-8d74-440d-82ef-81085323d9b8, 
3aaf56c4-e4b6-4b49-a21f-f5653164cad8, f1b5d2e1-cc14-450f-83b9-c9905a51ccb1, 
e9903d05-5e9d-4674-8b46-37a5b03886a3, 3981e8a6-63bd-409e-aa51-622f9701a9d8, 
5a6b0e90-919c-4480-9f96-0a11f19b700c, d5ea54dd-314f-4cd7-9a01-ec61f374a1e5, 
8a09bf32-5240-417f-a6cc-6009b6e099b4, 70055d1f-c586-44c6-91bd-7c2612290ead, 
34d63fbd-690c-4ee7-9f45-2271a67167ef, 4228b36d-a930-4675-aae1-12d99d6abedc, 
7cc96bc7-d3b4-4aae-8974-eb2fdb664b6d, 5e1bb59e-5bd7-4a4a-b6f8-bc9ccdc8b862, 
ac051b29-8646-4933-91d3-4054dcb7996d, c29761b5-d3eb-4be7-bd01-4a0e96e501f8, 
7a232c63-a378-4be3-a603-6c0ec1cff488, 804c8ece-58c6-4181-ad22-8cf8db1e7c52, 
cba9984e-12ed-4ed4-a3f4-38a3e43d206e, 603cc1f9-8193-4a5a-b214-6697b2203518, 
4f67c617-95cc-4cd1-b4a5-0fb525c1c9b2]
...
04.11.2015 23:43:36.878 *INFO * [VotingEventListener-i21] 
fe69e98e-38b1-42fa-aa37-fb16dd71d8c5: promote: promote to new established node 
/var/discovery/testing/establishedView/1d07b39a-f5b3-4e14-
bf3e-a09b0d2e8c6e

...

04.11.2015 23:43:49.791 *INFO * [VotingEventListener-i28] 
c81bf19a-fbf8-4605-a7b7-3d160229f2e2: analyzeVotings: deleting a timed out 
voting: a VotingView[viewId=3cb2332e-6b85-42f2-82cc-d7c952d2f398, 
id=1d07b39a-f5b3-4e14-bf3e-a09b0d2e8c6e, 
initiator=fe69e98e-38b1-42fa-aa37-fb16dd71d8c5, 
members=b32c362d-a3b0-46de-b917-98750884819e, 
6c07306f-a92e-455e-a962-cbc9c62af88a, bcbf490c-936d-487b-b81f-fac36b20237a, 
7047ae33-2dd4-43d1-a761-3d688d5e3d47, c81bf19a-fbf8-4605-a7b7-3d160229f2e2, 
67caf350-0669-4d36-98ce-a1fcdd5bf173, 4c0efefc-94c9-444d-9929-97ea80360e93, 
6d7a6243-5157-44aa-b8d8-99fb50a1f09b, fe69e98e-38b1-42fa-aa37-fb16dd71d8c5, 
b33239d5-40cd-41f7-ae2a-e43d49d6135d, 102b4486-8d74-440d-82ef-81085323d9b8, 
3aaf56c4-e4b6-4b49-a21f-f5653164cad8, f1b5d2e1-cc14-450f-83b9-c9905a51ccb1, 
e9903d05-5e9d-4674-8b46-37a5b03886a3, 3981e8a6-63bd-409e-aa51-622f9701a9d8, 
5a6b0e90-919c-4480-9f96-0a11f19b700c, d5ea54dd-314f-4cd7-9a01-ec61f374a1e5, 
8a09bf32-5240-417f-a6cc-6009b6e099b4, 70055d1f-c586-44c6-91bd-7c2612290ead, 
34d63fbd-690c-4ee7-9f45-2271a67167ef, 4228b36d-a930-4675-aae1-12d99d6abedc, 
7cc96bc7-d3b4-4aae-8974-eb2fdb664b6d, 5e1bb59e-5bd7-4a4a-b6f8-bc9ccdc8b862, 
ac051b29-8646-4933-91d3-4054dcb7996d, c29761b5-d3eb-4be7-bd01-4a0e96e501f8, 
7a232c63-a378-4be3-a603-6c0ec1cff488, 804c8ece-58c6-4181-ad22-8cf8db1e7c52, 
cba9984e-12ed-4ed4-a3f4-38a3e43d206e, 603cc1f9-8193-4a5a-b214-6697b2203518, 
4f67c617-95cc-4cd1-b4a5-0fb525c1c9b2]
...

04.11.2015 23:43:50.228 *ERROR* [VotingEventListener-i21] 
fe69e98e-38b1-42fa-aa37-fb16dd71d8c5: handleEvent: got a PersistenceException 
during votings analysis: org.apache.sling.api.resource.PersistenceException: 
Unable to commit changes.
org.apache.sling.api.resource.PersistenceException: Unable to commit changes.
at 
org.apache.sling.discovery.base.its.setup.mock.MockedResourceResolver.commit(MockedResourceResolver.java:323)
at 
org.apache.sling.discovery.impl.cluster.voting.VotingHandler.promote(VotingHandler.java:504)
at 
org.apache.sling.discovery.impl.cluster.voting.VotingHandler.analyzeVotings(VotingHandler.java:244)
at 
org.apache.sling.discovery.impl.cluster.voting.VotingHandler.handleEvent(VotingHandler.java:211)
at 
org.apache.sling.discovery.impl.setup.VotingEventListener$1.run(VotingEventListener.java:64)
at java.lang.Thread.run(Thread.java:724)
Caused by: javax.jcr.RepositoryException: Unable to update item: item.save()
at 
org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:265)
at 

Re: [VOTE] Release Apache Sling Testing OSGi Mock 1.7.0

[Stefan Egli]

+1

Cheers,
Stefan

On 04/11/15 22:43, "Stefan Seifert"  wrote:

>Hi,
>
>We solved 2 issues in this release:
>https://issues.apache.org/jira/browse/SLING/fixforversion/12333758
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-1363/
>
>You can use this UNIX script to download the release and verify the
>signatures:
>http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
>Usage:
>sh check_staged_release.sh 1363 /tmp/sling-staging
>
>Please vote to approve this release:
>
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
>
>This majority vote is open for at least 72 hours.
>
>
>stefan
>

Re: Removing loginAdministrative, how to test that, and service username conventions

[Bertrand Delacretaz]

Hi,

On Wed, Nov 4, 2015 at 6:51 PM, Carsten Ziegeler  wrote:
> ...I suggest we create for each feature a separate bundle with the user
> definition and the ACLs. The stuff gets then installed - like any other
> content - through the contentloader

So taking SLING-5227 as an example (the contrib/bgservlets module) you
suggest (option A) creating a companion bgservlets-users bundle that
provides the user/ACL definitions?

That would work, but I think my suggestion (option B) is simpler:
include those default definitions in the main bundle, but by default
to not install the service that processes them.

So by default no users/ACLs are created, and if you want backwards
compatibility or for testing purposes you just install a single bundle
that processes those embedded definitions.

This means those definitions need to use a different mechanism than
our current contentloader (or maybe a new plugin for that
contentloader) but that's not hard to implement.

-Bertrand

Re: [VOTE] Release Apache Sling discovery.commons 1.0.2, discovery.base 1.0.2, discovery.oak 1.0.2, discovery.impl 1.2.0

[Carsten Ziegeler]

+1


-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Updated] (SLING-5258) ensure a new establishedView (with different syncTokenId) always triggers a TOPOLOGY_CHANGED

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli updated SLING-5258:
---
Summary: ensure a new establishedView (with different syncTokenId) always 
triggers a TOPOLOGY_CHANGED  (was: add test that asserts a new establishedView 
always triggers a TOPOLOGY_CHANGED)

> ensure a new establishedView (with different syncTokenId) always triggers a 
> TOPOLOGY_CHANGED
> 
>
> Key: SLING-5258
> URL: https://issues.apache.org/jira/browse/SLING-5258
> 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
>
>
> With SLING-5256 the unerlying mechanisms in ViewStateManager etc ensure that 
> when a topology is passed to {{handleNewView}} that contains the very same 
> instances/properties but differs only in the localClusterSyncId (which is the 
> resource name of the voting in the discovery.impl case), that this then 
> properly generates a TOPOLOGY_CHANGED and a TOPOLOGY_CHANGING first (if 
> required).
> SLING-5058 was suggesting a different approach to achieving the same: to add 
> a {{viewCnt}}. Now SLING-5058 really becomes obsolete with SLING-5256 - but 
> that should be properly verified first - hence this ticket.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5258) ensure a new establishedView (with different syncTokenId) always triggers a TOPOLOGY_CHANGED

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14991722#comment-14991722
 ] 

Stefan Egli commented on SLING-5258:


this requires SLING-5256

> ensure a new establishedView (with different syncTokenId) always triggers a 
> TOPOLOGY_CHANGED
> 
>
> Key: SLING-5258
> URL: https://issues.apache.org/jira/browse/SLING-5258
> 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
>
>
> With SLING-5256 the unerlying mechanisms in ViewStateManager etc ensure that 
> when a topology is passed to {{handleNewView}} that contains the very same 
> instances/properties but differs only in the localClusterSyncId (which is the 
> resource name of the voting in the discovery.impl case), that this then 
> properly generates a TOPOLOGY_CHANGED and a TOPOLOGY_CHANGING first (if 
> required).
> SLING-5058 was suggesting a different approach to achieving the same: to add 
> a {{viewCnt}}. Now SLING-5058 really becomes obsolete with SLING-5256 - but 
> that should be properly verified first - hence this ticket.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-5258) ensure a new establishedView (with different syncTokenId) always triggers a TOPOLOGY_CHANGED

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli resolved SLING-5258.

Resolution: Fixed

Adjusted EstablishedClusterView appropriately (it now sets the 
localClusterSyncTokenId using the votingId) - plus added a new test that 
verifies this works. As mentioned, this builds ontop of SLING-5256.
rev: 1712784

> ensure a new establishedView (with different syncTokenId) always triggers a 
> TOPOLOGY_CHANGED
> 
>
> Key: SLING-5258
> URL: https://issues.apache.org/jira/browse/SLING-5258
> 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
>
>
> With SLING-5256 the unerlying mechanisms in ViewStateManager etc ensure that 
> when a topology is passed to {{handleNewView}} that contains the very same 
> instances/properties but differs only in the localClusterSyncId (which is the 
> resource name of the voting in the discovery.impl case), that this then 
> properly generates a TOPOLOGY_CHANGED and a TOPOLOGY_CHANGING first (if 
> required).
> SLING-5058 was suggesting a different approach to achieving the same: to add 
> a {{viewCnt}}. Now SLING-5058 really becomes obsolete with SLING-5256 - but 
> that should be properly verified first - hence this ticket.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-5058) introduce viewCnt to ./establishedView to be able to detect missing changes

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli resolved SLING-5058.

Resolution: Won't Fix

Won't implement this - instead SLING-5258 was implemented for discovery.impl 
1.2.2 that achieves the same (that you don't miss any changing establishedView, 
even if it keeps having the same instances) using the votingId (which always 
changes on each voting/establishedView) as the localClusterSyncTokenId - that 
in turn, thanks to SLING-5256, then results in the ViewStateManager treating 
the views as different and you'll get your TOPOLOGY_CHANGED event there..

> introduce viewCnt to ./establishedView to be able to detect missing changes
> ---
>
> Key: SLING-5058
> URL: https://issues.apache.org/jira/browse/SLING-5058
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Discovery Impl 1.1.6
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Minor
> Fix For: Discovery Impl 1.2.2
>
>
> With SLING-5030 when an instance detects that it is ISOLATED_FROM_TOPOLOGY it 
> will resets its {{leaderElectionId}} to ensure that it is not becoming leader 
> again. This works fine when the instance actually detects that it is 
> isolated. If the timing however is such that it does not detect the isolation 
> (eg when the isolation is for a very short time only), then it would not be 
> able to reset the {{leaderElectionId}}, thus it might become leader again - 
> which means that we have an unnecessary leader switch.
> This could be improved by introducing a {{viewCnt}} on the 
> {{./establishedView}} - and an instance could detect a gap in the viewCnt and 
> *then* reset the {{leaderElectionId}}.
> Putting this out-of-scope for discovery.impl 1.1.8 though



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[VOTE] Release Apache Sling IDE Tooling version 1.0.10

[Robert Munteanu]

Hi,

We solved 1 issue in this release:
https://issues.apache.org/jira/browse/SLING/fixforversion/12334041

There are still some outstanding issues:
https://issues.apache.org/jira/browse/SLING/component/12320908

The release candidate has been uploaded at
https://dist.apache.org/repos/dist/dev/sling, The release artifact is
the source bundle - org.apache.sling.ide.source-bundle-1.0.10.zip -
which can be used to build the project using

mvn clean package

The resulting binaries can be installed into an Eclipse instance from
the update site which is found at p2update/target/repository after
building the project.

You can use this UNIX script to download the release and verify the
signatures:
http://svn.apache.org/repos/asf/sling/trunk/tooling/ide/check_staged_re
lease.sh

Usage:
sh check_staged_release.sh 1.0.10 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours

Re: [RT] Handling resource (provider) changes

[Oliver Lietz]

On Wednesday 04 November 2015 18:45:00 Carsten Ziegeler wrote:
> The current active model for observation event for resources through
> OSGi events is modelled after JCR observation which means that for
> changes to a tree you might only get an event for the root of that tree.
> Especially when a whole tree is deleted, you get a single event.
> I assume, the same could in theory be true for adding.
> 
> The question is, whether we want to keep this model for the observation
> API we're about to implement. Especially as there are some additional
> things to consider:
> 
> 1. With Oak we could register observation listener which provide the
> information about every node removed/added/changed. So we can send out
> detailed events. Other resource provider implementations could simply
> follow that concept.

One event per resource makes implementing depending systems more 
straightforward, e.g. adding/removing data for a resource from a search index.
So +1.

> 2. We have three events for resources: added/removed/changed but also
> two events for resource providers. Obviously, if a resource provider is
> mounted at some path and is unregistered, the whole tree is removed.
> Again, we just send out a single event.
> 
> For 2. we definitely don't want to send out an event for every resource
> of that provider as that would be way too expensive.
> 
> For 1. we might start sending out too many events as well and I assume
> code is already prepared for that case.

What does that mean? _too_ many for whom? Can we process _too_ many events 
reliable?

> I think we should keep the optimization (and make this clear in the new
> observation API) and we probably should collapse the two special
> resource provider events into resource events: instead of sending out a
> resource provider added/removed, we send out a resource added/removed.
> Listeners right now usually handle all five events, and we could reduce
> this to three events, making everything compacter, nicer and easier to
> understand.
> 
> WDYT?

hm, added/removed resources and added/removed resource providers are from some 
aspects totally different use cases which I think should be seen as such.
I would like to differ between added/removed resources and added/removed 
resource providers. But having events for all resources added/removed when a 
resource provider is added/removed is also helpful. -1 for collapsing.

How rich are these events? Can a listener determine the provider for a 
resource? Can a listener determine if a resource was added/removed because its 
provider was added/removed? - forgive my ignorance, hadn't time to look into 
the new APIs so far.

Regards,
O.

> Regards
> Carsten

Re: [VOTE] Release Apache Sling IDE Tooling version 1.0.10

[Robert Munteanu]

On Thu, 2015-11-05 at 13:39 +0100, Robert Munteanu wrote:
> Please vote to approve this release:

+1

Robert

signature.asc
Description: This is a digitally signed message part

[jira] [Created] (SLING-5266) Adding org.mozilla.javascript.ast package in org.apache.sling.scripting.javascript bundle

[Mandeep Gandhi (JIRA)]

Mandeep Gandhi created SLING-5266:
-

 Summary: Adding org.mozilla.javascript.ast package in 
org.apache.sling.scripting.javascript  bundle 
 Key: SLING-5266
 URL: https://issues.apache.org/jira/browse/SLING-5266
 Project: Sling
  Issue Type: Task
  Components: General
Reporter: Mandeep Gandhi
Priority: Critical


There is a need of parsing javascript expression. For achieving this, there is 
a requirement of adding org.mozilla.javascript.ast package to the existing  
bundle (org.apache.sling.scripting.javascript ) and exporting it. 





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5267) TestOakSyncTokenService.testTwoNodesOneLeaving failed on jenkins, again

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14991522#comment-14991522
 ] 

Stefan Egli commented on SLING-5267:


the test actually had a bug: it was assuming 0 events to be received at a 
certain point - even though there was the possibility that an event 
(TOPOLOGY_INIT) was already sent then. 

> TestOakSyncTokenService.testTwoNodesOneLeaving failed on jenkins, again
> ---
>
> Key: SLING-5267
> URL: https://issues.apache.org/jira/browse/SLING-5267
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Commons 1.0.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Minor
> Fix For: Discovery Commons 1.0.4
>
>
> TestOakSyncTokenService.testTwoNodesOneLeaving failed on jenkins again, so 
> SLING-5225 wasn't enough.
> Details:
> https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.discovery.commons/2652/testReport/org.apache.sling.discovery.commons.providers.spi.base/TestOakSyncTokenService/testTwoNodesOneLeaving/
> {code}
> Regression
> org.apache.sling.discovery.commons.providers.spi.base.TestOakSyncTokenService.testTwoNodesOneLeaving
> Error Message
> expected:<0> but was:<1>
> Stacktrace
> java.lang.AssertionError: expected:<0> but was:<1>
>   at org.junit.Assert.fail(Assert.java:74)
>   at org.junit.Assert.failNotEquals(Assert.java:448)
>   at org.junit.Assert.assertEquals(Assert.java:102)
>   at org.junit.Assert.assertEquals(Assert.java:323)
>   at org.junit.Assert.assertEquals(Assert.java:319)
>   at 
> org.apache.sling.discovery.commons.providers.spi.base.TestOakSyncTokenService.testTwoNodesOneLeaving(TestOakSyncTokenService.java:168)
> Standard Output
> 04.11.2015 11:36:56.864 *INFO * [main] IndexUpdate: Found a new index node 
> [reference]. Reindexing is requested
> 04.11.2015 11:36:56.864 *WARN * [main] IndexUpdate: Missing index provider of 
> type [reference], requesting reindex on [/oak:index/reference]
> 04.11.2015 11:36:57.001 *INFO * [main] IdMapService: registerEventHandler: 
> bundleContext is null - cannot register
> 04.11.2015 11:36:57.001 *INFO * [main] IdMapService: init: init failed: 
> java.lang.Exception: No Descriptor value available
> 04.11.2015 11:36:57.001 *INFO * [main] IdMapService: backgroundCheck: 
> spawning background-thread for 'IdMapService-initializer'
> 04.11.2015 11:36:57.002 *INFO * [main] OakBacklogClusterSyncService: 
> activate: activated with slingId=5575618b-440a-4370-a27c-3223017bc528
> 04.11.2015 11:36:57.002 *INFO * [main] ViewStateManagerImpl: 
> handleNewViewNonDelayed: ClusterSyncService set - invoking...
> 04.11.2015 11:36:57.002 *INFO * [main] ViewStateManagerImpl: 
> handleNewViewNonDelayed: invoking waitForAsyncEvents, then clusterSyncService 
> (modCnt=3)
> 04.11.2015 11:36:57.002 *INFO * [Discovery-AsyncEventSender] 
> AsyncEventSender: AsyncEventSender.run: started.
> 04.11.2015 11:36:57.002 *INFO * [Discovery-AsyncEventSender] 
> ViewStateManagerImpl: handleNewViewNonDelayed/waitForAsyncEvents.run: done, 
> now invoking consistencyService (modCnt=3)
> 04.11.2015 11:36:57.002 *INFO * [Discovery-AsyncEventSender] 
> OakBacklogClusterSyncService: sync: doing wait-for-backlog part for 
> view=DefaultTopologyView[current=true, num=2, 
> instances=a905fe58-aa7e-4861-bc9e-3d742746b270[local=false,leader=false],5575618b-440a-4370-a27c-3223017bc528[local=true,leader=true]]
> 04.11.2015 11:36:57.003 *INFO * [Discovery-AsyncEventSender] 
> OakBacklogClusterSyncService: waitWhileBacklog: could not initialize...
> 04.11.2015 11:36:57.003 *INFO * [main] IdMapService: registerEventHandler: 
> bundleContext is null - cannot register
> 04.11.2015 11:36:57.005 *INFO * [Discovery-AsyncEventSender] 
> OakBacklogClusterSyncService: backgroundCheck: spawning background-thread for 
> 'OakBacklogClusterSyncService-backlog-waiting'
> 04.11.2015 11:36:57.005 *INFO * [main] IdMapService: init: init failed: 
> java.lang.Exception: No Descriptor value available
> 04.11.2015 11:36:57.005 *INFO * [main] IdMapService: backgroundCheck: 
> spawning background-thread for 'IdMapService-initializer'
> 04.11.2015 11:36:57.008 *INFO * [IdMapService-initializer] IdMapService: 
> init: added the following mapping: 
> slingId=5575618b-440a-4370-a27c-3223017bc528 to discovery-lite id=1
> 04.11.2015 11:36:57.010 *INFO * [main] OakBacklogClusterSyncService: 
> activate: activated with slingId=a905fe58-aa7e-4861-bc9e-3d742746b270
> 04.11.2015 11:36:57.011 *INFO * 
> [OakBacklogClusterSyncService-backlog-waiting] IdMapService: toSlingId: 
> mapping for 1 to 5575618b-440a-4370-a27c-3223017bc528 was newly added.
> 04.11.2015 11:36:57.011 *INFO * 
> [OakBacklogClusterSyncService-backlog-waiting] 

[jira] [Created] (SLING-5267) TestOakSyncTokenService.testTwoNodesOneLeaving failed on jenkins, again

[Stefan Egli (JIRA)]

Stefan Egli created SLING-5267:
--

 Summary: TestOakSyncTokenService.testTwoNodesOneLeaving failed on 
jenkins, again
 Key: SLING-5267
 URL: https://issues.apache.org/jira/browse/SLING-5267
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Discovery Commons 1.0.2
Reporter: Stefan Egli
Assignee: Stefan Egli
Priority: Minor
 Fix For: Discovery Commons 1.0.4


TestOakSyncTokenService.testTwoNodesOneLeaving failed on jenkins again, so 
SLING-5225 wasn't enough.
Details:
https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.discovery.commons/2652/testReport/org.apache.sling.discovery.commons.providers.spi.base/TestOakSyncTokenService/testTwoNodesOneLeaving/

{code}
Regression

org.apache.sling.discovery.commons.providers.spi.base.TestOakSyncTokenService.testTwoNodesOneLeaving

Error Message

expected:<0> but was:<1>

Stacktrace

java.lang.AssertionError: expected:<0> but was:<1>
at org.junit.Assert.fail(Assert.java:74)
at org.junit.Assert.failNotEquals(Assert.java:448)
at org.junit.Assert.assertEquals(Assert.java:102)
at org.junit.Assert.assertEquals(Assert.java:323)
at org.junit.Assert.assertEquals(Assert.java:319)
at 
org.apache.sling.discovery.commons.providers.spi.base.TestOakSyncTokenService.testTwoNodesOneLeaving(TestOakSyncTokenService.java:168)

Standard Output

04.11.2015 11:36:56.864 *INFO * [main] IndexUpdate: Found a new index node 
[reference]. Reindexing is requested
04.11.2015 11:36:56.864 *WARN * [main] IndexUpdate: Missing index provider of 
type [reference], requesting reindex on [/oak:index/reference]
04.11.2015 11:36:57.001 *INFO * [main] IdMapService: registerEventHandler: 
bundleContext is null - cannot register
04.11.2015 11:36:57.001 *INFO * [main] IdMapService: init: init failed: 
java.lang.Exception: No Descriptor value available
04.11.2015 11:36:57.001 *INFO * [main] IdMapService: backgroundCheck: spawning 
background-thread for 'IdMapService-initializer'
04.11.2015 11:36:57.002 *INFO * [main] OakBacklogClusterSyncService: activate: 
activated with slingId=5575618b-440a-4370-a27c-3223017bc528
04.11.2015 11:36:57.002 *INFO * [main] ViewStateManagerImpl: 
handleNewViewNonDelayed: ClusterSyncService set - invoking...
04.11.2015 11:36:57.002 *INFO * [main] ViewStateManagerImpl: 
handleNewViewNonDelayed: invoking waitForAsyncEvents, then clusterSyncService 
(modCnt=3)
04.11.2015 11:36:57.002 *INFO * [Discovery-AsyncEventSender] AsyncEventSender: 
AsyncEventSender.run: started.
04.11.2015 11:36:57.002 *INFO * [Discovery-AsyncEventSender] 
ViewStateManagerImpl: handleNewViewNonDelayed/waitForAsyncEvents.run: done, now 
invoking consistencyService (modCnt=3)
04.11.2015 11:36:57.002 *INFO * [Discovery-AsyncEventSender] 
OakBacklogClusterSyncService: sync: doing wait-for-backlog part for 
view=DefaultTopologyView[current=true, num=2, 
instances=a905fe58-aa7e-4861-bc9e-3d742746b270[local=false,leader=false],5575618b-440a-4370-a27c-3223017bc528[local=true,leader=true]]
04.11.2015 11:36:57.003 *INFO * [Discovery-AsyncEventSender] 
OakBacklogClusterSyncService: waitWhileBacklog: could not initialize...
04.11.2015 11:36:57.003 *INFO * [main] IdMapService: registerEventHandler: 
bundleContext is null - cannot register
04.11.2015 11:36:57.005 *INFO * [Discovery-AsyncEventSender] 
OakBacklogClusterSyncService: backgroundCheck: spawning background-thread for 
'OakBacklogClusterSyncService-backlog-waiting'
04.11.2015 11:36:57.005 *INFO * [main] IdMapService: init: init failed: 
java.lang.Exception: No Descriptor value available
04.11.2015 11:36:57.005 *INFO * [main] IdMapService: backgroundCheck: spawning 
background-thread for 'IdMapService-initializer'
04.11.2015 11:36:57.008 *INFO * [IdMapService-initializer] IdMapService: init: 
added the following mapping: slingId=5575618b-440a-4370-a27c-3223017bc528 to 
discovery-lite id=1
04.11.2015 11:36:57.010 *INFO * [main] OakBacklogClusterSyncService: activate: 
activated with slingId=a905fe58-aa7e-4861-bc9e-3d742746b270
04.11.2015 11:36:57.011 *INFO * [OakBacklogClusterSyncService-backlog-waiting] 
IdMapService: toSlingId: mapping for 1 to 5575618b-440a-4370-a27c-3223017bc528 
was newly added.
04.11.2015 11:36:57.011 *INFO * [OakBacklogClusterSyncService-backlog-waiting] 
OakBacklogClusterSyncService: getBacklogStatus: no backlog (anymore)
04.11.2015 11:36:57.011 *INFO * [OakBacklogClusterSyncService-backlog-waiting] 
OakBacklogClusterSyncService: waitWhileBacklog: no backlog (anymore), done.
04.11.2015 11:36:57.014 *INFO * [OakBacklogClusterSyncService-backlog-waiting] 
ViewStateManagerImpl: consistencyService.callback.run: invoking 
doHandleConsistent.
04.11.2015 11:36:57.015 *INFO * [IdMapService-initializer] IdMapService: init: 
init failed: java.lang.Exception: No Descriptor value available

Re: [VOTE] Release Apache Sling discovery.commons 1.0.2, discovery.base 1.0.2, discovery.oak 1.0.2, discovery.impl 1.2.0

[Stefan Egli]

missine one vote, anyone?

thx!
stefan

On 02/11/15 18:13, "Stefan Egli"  wrote:

>Hi,
>
>For the following three, new releases we solved:
>
>Discovery Commons 1.0.2 - 2 issues
>https://issues.apache.org/jira/browse/SLING/fixforversion/12333980
>
>Discovery Base 1.0.2 - 2 issues
>https://issues.apache.org/jira/browse/SLING/fixforversion/12333979
>
>Discovery Oak 1.0.2 - 2 issues
>https://issues.apache.org/jira/browse/SLING/fixforversion/12333978
>
>Discovery Impl 1.2.0 - 13 issues
>https://issues.apache.org/jira/browse/SLING/fixforversion/12333413
>
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-1362/
>
>You can use this UNIX script to download the release and verify the
>signatures:
>http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
>Usage:
>sh check_staged_release.sh 1362 /tmp/sling-staging
>
>Please vote to approve this release:
>
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
>
>This majority vote is open for at least 72 hours.
>
>Cheers,
>
>Stefan
>
>

[jira] [Commented] (SLING-5193) Installing the Sling IDE Tooling causes 'Open With...' to disappear

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14991576#comment-14991576
 ] 

Robert Munteanu commented on SLING-5193:


I renamed the branch to sling-ide-tooling-1.0.x ( as suggested on dev@sling ).  
I have also changed the version in trunk, as you have suggested. To stay in 
line with the odd/even release pattern I have set the version to 1.0.99.

I will start a release vote later today.

> Installing the Sling IDE Tooling causes 'Open With...' to disappear
> ---
>
> Key: SLING-5193
> URL: https://issues.apache.org/jira/browse/SLING-5193
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.0
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Critical
> Fix For: Sling Eclipse IDE 1.1.0
>
> Attachments: sling-ide-tooling-missing-open-with.png
>
>
> After installing the Sling IDE Tooling the 'Open' and 'Open With...' commands 
> are gone from the context menu which appears in the Project Explorer.
> The root cause is the eclipse-ui/plugin.xml which contributes
> {code}   
> class="org.apache.sling.ide.eclipse.ui.nav.PackageExplorerOpenActionProvider"
>
> id="org.apache.sling.ide.eclipse.ui.nav.actions.OpenActions"
>
> overrides="org.eclipse.jdt.ui.navigator.actions.OpenActions">{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-5267) TestOakSyncTokenService.testTwoNodesOneLeaving failed on jenkins, again

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli resolved SLING-5267.

Resolution: Fixed

bq. fixed testTwoNodesOneLeaving by making wait times safer, asserting for 
background-runnable done-state, plus added more logging in case this one is 
still not perfectly stable on jenkins
in rev 1712742

> TestOakSyncTokenService.testTwoNodesOneLeaving failed on jenkins, again
> ---
>
> Key: SLING-5267
> URL: https://issues.apache.org/jira/browse/SLING-5267
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Commons 1.0.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Minor
> Fix For: Discovery Commons 1.0.4
>
>
> TestOakSyncTokenService.testTwoNodesOneLeaving failed on jenkins again, so 
> SLING-5225 wasn't enough.
> Details:
> https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.discovery.commons/2652/testReport/org.apache.sling.discovery.commons.providers.spi.base/TestOakSyncTokenService/testTwoNodesOneLeaving/
> {code}
> Regression
> org.apache.sling.discovery.commons.providers.spi.base.TestOakSyncTokenService.testTwoNodesOneLeaving
> Error Message
> expected:<0> but was:<1>
> Stacktrace
> java.lang.AssertionError: expected:<0> but was:<1>
>   at org.junit.Assert.fail(Assert.java:74)
>   at org.junit.Assert.failNotEquals(Assert.java:448)
>   at org.junit.Assert.assertEquals(Assert.java:102)
>   at org.junit.Assert.assertEquals(Assert.java:323)
>   at org.junit.Assert.assertEquals(Assert.java:319)
>   at 
> org.apache.sling.discovery.commons.providers.spi.base.TestOakSyncTokenService.testTwoNodesOneLeaving(TestOakSyncTokenService.java:168)
> Standard Output
> 04.11.2015 11:36:56.864 *INFO * [main] IndexUpdate: Found a new index node 
> [reference]. Reindexing is requested
> 04.11.2015 11:36:56.864 *WARN * [main] IndexUpdate: Missing index provider of 
> type [reference], requesting reindex on [/oak:index/reference]
> 04.11.2015 11:36:57.001 *INFO * [main] IdMapService: registerEventHandler: 
> bundleContext is null - cannot register
> 04.11.2015 11:36:57.001 *INFO * [main] IdMapService: init: init failed: 
> java.lang.Exception: No Descriptor value available
> 04.11.2015 11:36:57.001 *INFO * [main] IdMapService: backgroundCheck: 
> spawning background-thread for 'IdMapService-initializer'
> 04.11.2015 11:36:57.002 *INFO * [main] OakBacklogClusterSyncService: 
> activate: activated with slingId=5575618b-440a-4370-a27c-3223017bc528
> 04.11.2015 11:36:57.002 *INFO * [main] ViewStateManagerImpl: 
> handleNewViewNonDelayed: ClusterSyncService set - invoking...
> 04.11.2015 11:36:57.002 *INFO * [main] ViewStateManagerImpl: 
> handleNewViewNonDelayed: invoking waitForAsyncEvents, then clusterSyncService 
> (modCnt=3)
> 04.11.2015 11:36:57.002 *INFO * [Discovery-AsyncEventSender] 
> AsyncEventSender: AsyncEventSender.run: started.
> 04.11.2015 11:36:57.002 *INFO * [Discovery-AsyncEventSender] 
> ViewStateManagerImpl: handleNewViewNonDelayed/waitForAsyncEvents.run: done, 
> now invoking consistencyService (modCnt=3)
> 04.11.2015 11:36:57.002 *INFO * [Discovery-AsyncEventSender] 
> OakBacklogClusterSyncService: sync: doing wait-for-backlog part for 
> view=DefaultTopologyView[current=true, num=2, 
> instances=a905fe58-aa7e-4861-bc9e-3d742746b270[local=false,leader=false],5575618b-440a-4370-a27c-3223017bc528[local=true,leader=true]]
> 04.11.2015 11:36:57.003 *INFO * [Discovery-AsyncEventSender] 
> OakBacklogClusterSyncService: waitWhileBacklog: could not initialize...
> 04.11.2015 11:36:57.003 *INFO * [main] IdMapService: registerEventHandler: 
> bundleContext is null - cannot register
> 04.11.2015 11:36:57.005 *INFO * [Discovery-AsyncEventSender] 
> OakBacklogClusterSyncService: backgroundCheck: spawning background-thread for 
> 'OakBacklogClusterSyncService-backlog-waiting'
> 04.11.2015 11:36:57.005 *INFO * [main] IdMapService: init: init failed: 
> java.lang.Exception: No Descriptor value available
> 04.11.2015 11:36:57.005 *INFO * [main] IdMapService: backgroundCheck: 
> spawning background-thread for 'IdMapService-initializer'
> 04.11.2015 11:36:57.008 *INFO * [IdMapService-initializer] IdMapService: 
> init: added the following mapping: 
> slingId=5575618b-440a-4370-a27c-3223017bc528 to discovery-lite id=1
> 04.11.2015 11:36:57.010 *INFO * [main] OakBacklogClusterSyncService: 
> activate: activated with slingId=a905fe58-aa7e-4861-bc9e-3d742746b270
> 04.11.2015 11:36:57.011 *INFO * 
> [OakBacklogClusterSyncService-backlog-waiting] IdMapService: toSlingId: 
> mapping for 1 to 5575618b-440a-4370-a27c-3223017bc528 was newly added.
> 04.11.2015 11:36:57.011 *INFO * 
> [OakBacklogClusterSyncService-backlog-waiting] 

RE: [VOTE] Release Apache Sling discovery.commons 1.0.2, discovery.base 1.0.2, discovery.oak 1.0.2, discovery.impl 1.2.0

[Stefan Seifert]

+1

[jira] [Updated] (SLING-5193) Installing the Sling IDE Tooling causes 'Open With...' to disappear

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated SLING-5193:
---
Fix Version/s: Sling Eclipse IDE 1.0.10

> Installing the Sling IDE Tooling causes 'Open With...' to disappear
> ---
>
> Key: SLING-5193
> URL: https://issues.apache.org/jira/browse/SLING-5193
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.0
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Critical
> Fix For: Sling Eclipse IDE 1.1.0, Sling Eclipse IDE 1.0.10
>
> Attachments: sling-ide-tooling-missing-open-with.png
>
>
> After installing the Sling IDE Tooling the 'Open' and 'Open With...' commands 
> are gone from the context menu which appears in the Project Explorer.
> The root cause is the eclipse-ui/plugin.xml which contributes
> {code}   
> class="org.apache.sling.ide.eclipse.ui.nav.PackageExplorerOpenActionProvider"
>
> id="org.apache.sling.ide.eclipse.ui.nav.actions.OpenActions"
>
> overrides="org.eclipse.jdt.ui.navigator.actions.OpenActions">{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (SLING-5149) Generate OSGi subsystem intermediary file in slingstart-maven-plugin

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu reassigned SLING-5149:
--

Assignee: Robert Munteanu

> 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
>Assignee: Robert Munteanu
> 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)

[RESULT][VOTE] Release Apache Sling discovery.commons 1.0.2, discovery.base 1.0.2, discovery.oak 1.0.2, discovery.impl 1.2.0

[Stefan Egli]

The vote passed with 3 binding +1 votes, thx. I'll promote the release.

Cheers,
Stefan

--

On 02/11/15 18:13, "Stefan Egli"  wrote:

>Hi,
>
>For the following three, new releases we solved:
>
>Discovery Commons 1.0.2 - 2 issues
>https://issues.apache.org/jira/browse/SLING/fixforversion/12333980
>
>Discovery Base 1.0.2 - 2 issues
>https://issues.apache.org/jira/browse/SLING/fixforversion/12333979
>
>Discovery Oak 1.0.2 - 2 issues
>https://issues.apache.org/jira/browse/SLING/fixforversion/12333978
>
>Discovery Impl 1.2.0 - 13 issues
>https://issues.apache.org/jira/browse/SLING/fixforversion/12333413
>
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-1362/
>
>You can use this UNIX script to download the release and verify the
>signatures:
>http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
>Usage:
>sh check_staged_release.sh 1362 /tmp/sling-staging
>
>Please vote to approve this release:
>
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
>
>This majority vote is open for at least 72 hours.
>
>Cheers,
>
>Stefan
>
>

[jira] [Commented] (SLING-920) Sling Jenkins setup

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14992030#comment-14992030
 ] 

Robert Munteanu commented on SLING-920:
---

Switched sling-trunk-1.7 to use 'OpenJDK 1.7 ( Ubuntu only )' as a possible 
workaround for INFRA-10557

> Sling Jenkins setup
> ---
>
> Key: SLING-920
> URL: https://issues.apache.org/jira/browse/SLING-920
> Project: Sling
>  Issue Type: Task
>  Components: Testing
>Reporter: Bertrand Delacretaz
>
> Use this issue to record changes to the Jenkins setup at 
> https://builds.apache.org/view/S-Z/view/Sling/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: SIGSEGV on jenkins for sling-trunk-1.7

[Stefan Egli]

On 05/11/15 18:22, "Robert Munteanu"  wrote:

>On Thu, 2015-11-05 at 17:57 +0100, Stefan Egli wrote:
>> Hi,
>> 
>> There was this SIGSEGV happening in the previous run for sling-trunk-
>> 1.7
>> [0].
>> 
>> Just a wild guess if it would be similar to [1]: perhaps the process
>> doesn't have enough java heap too?
>
>That would be https://issues.apache.org/jira/browse/INFRA-10557 . It
>has no solution though, just complatins :-)
>
>I am not sure that adding more memory will help - I don't think it
>fails on the first GC. Perhaps we can use a more recent Java version?
>
>I see that on Jenkins we have 'JDK 1.7 ( latest )', but 7u25 is
>definitely not latest :-) I have switched to 'OpenJDK 1.7 ( Ubuntu only
>)', let's see if that helps.

Ok cool, let's see.

Cheers,
Stefan

>
>Robert
>
>
>
>> 
>> How can we increase that? (I've seen OOME on jenkins earlier
>> actually, so
>> I think it would be good anyway)
>> 
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  SIGSEGV (0xb) at pc=0xf6814654, pid=1179, tid=2711087936
>> #
>> # JRE version: 7.0_25-b15
>> # Java VM: Java HotSpot(TM) Server VM (23.25-b01 mixed mode linux-x86
>> )
>> # Problematic frame:
>> # C  [libnet.so+0x14654]  _fini+0x1d0c
>> #
>> # Failed to write core dump. Core dumps have been disabled. To enable
>> core
>> dumping, try "ulimit -c unlimited" before starting Java again
>> #
>> # An error report file with more information is saved as:
>> # 
>> /home/jenkins/jenkins-slave/workspace/sling-trunk-
>> 1.7/trunk/bundles/scripti
>> ng/sightly/testing/target/oak-35596/hs_err_pid1179.log
>> #
>> # If you would like to submit a bug report, please visit:
>> #   http://bugreport.sun.com/bugreport/crash.jsp
>> # The crash happened outside the Java Virtual Machine in native code.
>> # See problematic frame for where to report the bug.
>> #
>> 
>> Cheers,
>> Stefan
>> --
>> [0] - https://builds.apache.org/job/sling-trunk-1.7/2667/console
>> [1] - http://stackoverflow.com/questions/21964620/java-7-update-25-cr
>> ash
>> 
>> 
>

[jira] [Created] (SLING-5268) Make Sling Connector IDE Independent

[Andreas Schaefer (JIRA)]

Andreas Schaefer created SLING-5268:
---

 Summary: Make Sling Connector IDE Independent
 Key: SLING-5268
 URL: https://issues.apache.org/jira/browse/SLING-5268
 Project: Sling
  Issue Type: Improvement
  Components: Tooling
Reporter: Andreas Schaefer


Sling Connector code in the IDE Tooling needs to be IDE independent to make it 
possible to be used in other IDEs like IntelliJ, NetBeans etc. There are two 
main areas:

1) Modules should not contain OSGi references as for example IntelliJ does not 
use OSGi internally. IDE can wrap a module inside OSGi but shouldn't require it.

2) Code that is used to check or deploy resources on Sling should be IDE 
independent. For example ResourceChangeCommandFactory should not be using 
I-classes from Eclipse but rather Interfaces that can be implemented by any IDE 
to their requirements.

The main reason for doing this is to ease the adoption of new code from this 
project as well as making it easier for new IDE to adopt.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (SLING-5210) Create an installer factory/transformer for slingstart-maven-plugin generated intermediary subsystem files

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu reassigned SLING-5210:
--

Assignee: Robert Munteanu

> 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
>Assignee: Robert Munteanu
> 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-5149) Generate OSGi subsystem intermediary file in slingstart-maven-plugin

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu resolved SLING-5149.

Resolution: Fixed

Patch applied in https://svn.apache.org/r1712784 , thanks for the contribution!

> 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
>Assignee: Robert Munteanu
> 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)

Re: Making Sling Connector in Sling Tooling IDE independent issue

[Robert Munteanu]

Hi Andy,

On Thu, 2015-11-05 at 08:14 -0800, Andreas Schaefer Sr. wrote:
> Hi
> 
> I create a new issue to make the Sling Connector (anything that
> checks or deploys resources onto Sling) IDE independent:
> 
> https://issues.apache.org/jira/browse/SLING-5268
> 
> When I developed the first draft of the IntelliJ plugin my biggest
> problem was to incorporate the Sling Connector code into the IntelliJ
> plugin. There were two main issues I had to deal with: OSGi bundles
> and Eclipse’s I-classes.
> 
> In order to make it easier to create new Sling plugin for other IDEs
> and to ease the adoption of updates the Sling Connector code should
> be made IDE independent by Interfaces / Abstract classes.

I would be happy to make the code as consumable as possible for other
IDEs. I tried to keep the concerns separated as much as possible, but
sometimes that hasn't worked out :-)

And for some things ( e.g. ResourceChangeCommandFactory ) I chose to
make the implementation Eclipse-specific as I had no idea how it would
work for other IDEs.

Let's continue the discussion on the Jira issue, we probably need to
create specific sub-tasks for the individual problems that need to be
fixed.

Cheers,

Robert

SIGSEGV on jenkins for sling-trunk-1.7

[Stefan Egli]

Hi,

There was this SIGSEGV happening in the previous run for sling-trunk-1.7
[0].

Just a wild guess if it would be similar to [1]: perhaps the process
doesn't have enough java heap too?

How can we increase that? (I've seen OOME on jenkins earlier actually, so
I think it would be good anyway)

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xf6814654, pid=1179, tid=2711087936
#
# JRE version: 7.0_25-b15
# Java VM: Java HotSpot(TM) Server VM (23.25-b01 mixed mode linux-x86 )
# Problematic frame:
# C  [libnet.so+0x14654]  _fini+0x1d0c
#
# Failed to write core dump. Core dumps have been disabled. To enable core
dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# 
/home/jenkins/jenkins-slave/workspace/sling-trunk-1.7/trunk/bundles/scripti
ng/sightly/testing/target/oak-35596/hs_err_pid1179.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

Cheers,
Stefan
--
[0] - https://builds.apache.org/job/sling-trunk-1.7/2667/console
[1] - http://stackoverflow.com/questions/21964620/java-7-update-25-crash

[jira] [Updated] (SLING-5210) Create an installer factory/transformer for slingstart-maven-plugin generated intermediary subsystem files

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated SLING-5210:
---
Fix Version/s: Installer Subsystem Base Factory 1.0.0

> 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
>Assignee: Robert Munteanu
> Fix For: Installer Subsystem Base Factory 1.0.0
>
> 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)

Making Sling Connector in Sling Tooling IDE independent issue

[Andreas Schaefer Sr.]

Hi

I create a new issue to make the Sling Connector (anything that checks or 
deploys resources onto Sling) IDE independent:

https://issues.apache.org/jira/browse/SLING-5268

When I developed the first draft of the IntelliJ plugin my biggest problem was 
to incorporate the Sling Connector code into the IntelliJ plugin. There were 
two main issues I had to deal with: OSGi bundles and Eclipse’s I-classes.

In order to make it easier to create new Sling plugin for other IDEs and to 
ease the adoption of updates the Sling Connector code should be made IDE 
independent by Interfaces / Abstract classes.

Cheers - Andy

[jira] [Updated] (SLING-5268) Make Sling Connector IDE Independent

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated SLING-5268:
---
Component/s: (was: Tooling)
 IDE

> Make Sling Connector IDE Independent
> 
>
> Key: SLING-5268
> URL: https://issues.apache.org/jira/browse/SLING-5268
> Project: Sling
>  Issue Type: Improvement
>  Components: IDE
>Reporter: Andreas Schaefer
>
> Sling Connector code in the IDE Tooling needs to be IDE independent to make 
> it possible to be used in other IDEs like IntelliJ, NetBeans etc. There are 
> two main areas:
> 1) Modules should not contain OSGi references as for example IntelliJ does 
> not use OSGi internally. IDE can wrap a module inside OSGi but shouldn't 
> require it.
> 2) Code that is used to check or deploy resources on Sling should be IDE 
> independent. For example ResourceChangeCommandFactory should not be using 
> I-classes from Eclipse but rather Interfaces that can be implemented by any 
> IDE to their requirements.
> The main reason for doing this is to ease the adoption of new code from this 
> project as well as making it easier for new IDE to adopt.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-5210) Create an installer factory/transformer for slingstart-maven-plugin generated intermediary subsystem files

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu resolved SLING-5210.

Resolution: Fixed

Thanks for the submission, I've applied it in https://svn.apache.org/r1712821

> 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
>Assignee: Robert Munteanu
> 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)

IDE check_staged_release.sh script ( Was: [VOTE] Release Apache Sling IDE Tooling version 1.0.10 )

[Robert Munteanu]

Hi Stefan,

On Thu, 2015-11-05 at 14:55 +0100, Stefan Egli wrote:
> just a small note: for me it downloaded both the 1.0.10 and the
> previous
> 1.0.8 - perhaps a bug in check_staged_release.sh? but wouldn't block
> the
> vote anyway of course..

I forgot to remove the old sling-ide-tooling 1.0.8 directory from the
staging area, thanks for report.

Now it should just download 1.0.10 .

Robert

[jira] [Commented] (SLING-5134) Donation of sling pipes

[Craig L Russell (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14993000#comment-14993000
 ] 

Craig L Russell commented on SLING-5134:


When secretary files an icla, shortly thereafter the public name shows up on 
http://people.apache.org/committer-index.html

You can find Nicolas Peltier listed there. Any time after his comment on 
26/Oct/15 13:04 this could have been verified. 

When secretary receives an icla, and the icla names a "notify project", then 
that project is copied on the acknowledgement email, as Oliver points out. 
There was no entry on the "notify project" field of this icla.


> 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)

Making service user and ACL provisioning available in Sling

[Robert Munteanu]

Hi,

In the context of removing all loginAdministrative usages from AEM 6.2
we have started removing these usages from Sling. While we do have a
way of using service users in Sling, we do not (yet) have a way of 
creating service users and ACLs, except by using code.

In AEM, we are already using content packages to deploy users and ACLs 
and we want  to avoid creating a Sling-only mechanism. Therefore the
question is - what options do we have for creating service users and
ACLs that would work for all of Sling/AEM/Granite?

I've listed the options that I know of at [1], please add any that I 
might've missed, including discussion references. Please do not start a
discussion on pros and cons of each option yet ; let's get all the 
options on the table before.

Thanks,

Robert

[1]: https://wiki.corp.adobe.com/display/~rmuntean/Making+service+user+
and+ACL+provisioning+available+in+Sling

[jira] [Commented] (SLING-5263) Request to implement junit test cases for LogSupport.java

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14991818#comment-14991818
 ] 

Robert Munteanu commented on SLING-5263:


[~tiennv90] - I tried but can't assign this to you, probably due to 
restrictions imposed by the default Jira workflow. But it does not matter - 
usually the developer who commits the changes ( and therefore validates that 
they are correct and takes responsibility for them ) assigns the issue to 
themselves.

There is no request to be approved, just attach a patch or send a pull request 
and we'll take it from there :-)

> Request to implement junit test cases for LogSupport.java
> -
>
> Key: SLING-5263
> URL: https://issues.apache.org/jira/browse/SLING-5263
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Tien Nguyen Viet
>Priority: Trivial
>
> org.apache.sling.commons.logservice.internal.LogSupport.java is not 100% 
> covered by junit test cases, can i request to let me implement the test cases 
> ?
> CC: [~cziegeler]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-4380) Use sling mocks for the discovery impl tests

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-4380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli updated SLING-4380:
---
Fix Version/s: (was: Discovery Impl 1.2.2)

> 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
>
> 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] [Reopened] (SLING-5264) DiscoveryServiceImplTest.testThirtyInstances failed on jenkins

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli reopened SLING-5264:


test failed again - perhaps some swallowed runtimeexception/error :
https://builds.apache.org/job/sling-trunk-1.8/1946/console
reopening..

> DiscoveryServiceImplTest.testThirtyInstances failed on jenkins
> --
>
> Key: SLING-5264
> URL: https://issues.apache.org/jira/browse/SLING-5264
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Impl 1.2.0, Discovery Base 1.0.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Minor
> Fix For: Discovery Impl 1.2.2, Discovery Base 1.0.4
>
> Attachments: testThirtyInstances.txt.gz
>
>
> DiscoveryServiceImplTest.testThirtyInstances failed on jenkins: 
> https://builds.apache.org/job/sling-trunk-1.7/2659/
> {code}
> DiscoveryServiceImplTest>AbstractDiscoveryServiceTest.testThirtyInstances:304->AbstractDiscoveryServiceTest.startRetryLoop:311->AbstractDiscoveryServiceTest.startRetryLoop:315
>  RetryLoop failed, condition is false after 100 seconds: null
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5264) DiscoveryServiceImplTest.testThirtyInstances failed on jenkins

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14991659#comment-14991659
 ] 

Stefan Egli commented on SLING-5264:


added some more logging in 1712764

> DiscoveryServiceImplTest.testThirtyInstances failed on jenkins
> --
>
> Key: SLING-5264
> URL: https://issues.apache.org/jira/browse/SLING-5264
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Impl 1.2.0, Discovery Base 1.0.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Minor
> Fix For: Discovery Impl 1.2.2, Discovery Base 1.0.4
>
> Attachments: testThirtyInstances.txt.gz
>
>
> DiscoveryServiceImplTest.testThirtyInstances failed on jenkins: 
> https://builds.apache.org/job/sling-trunk-1.7/2659/
> {code}
> DiscoveryServiceImplTest>AbstractDiscoveryServiceTest.testThirtyInstances:304->AbstractDiscoveryServiceTest.startRetryLoop:311->AbstractDiscoveryServiceTest.startRetryLoop:315
>  RetryLoop failed, condition is false after 100 seconds: null
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [RT] Handling resource (provider) changes

[Dominik Süß]

Hi everyone,

as I get the point that having a broadcasted event for each any any change
in the ResourceTree I fear that this comes at a high price. I think it
would be good to have some mechanisms to
a) toggle of eventing for specific subtrees completely
b) just create an event for a specific subtree whenever sth changed in a
given interval
c) being able to register interest for specific paths / properties and
therefore just send event if there is any listener that claims to have
interest
For the existing behavior a listener could just register for "everything"
but it would be possible to tweak all eventlisteners in a way that reduces
the amount of events that are fired significantly (which would probably
allow to further narrow down what kind of observation we need in oak)

The oak team has tweaked in the area quite a lot to provide better scaling
of eventing - it would be a shame if our sling eventing wouldn't make use
of this or even eliminates the benefits of this.

Cheers
Dominik


On Thu, Nov 5, 2015 at 2:23 PM, Carsten Ziegeler 
wrote:

> Am 05.11.15 um 14:01 schrieb Oliver Lietz:
> > On Wednesday 04 November 2015 18:45:00 Carsten Ziegeler wrote:
> >> The current active model for observation event for resources through
> >> OSGi events is modelled after JCR observation which means that for
> >> changes to a tree you might only get an event for the root of that tree.
> >> Especially when a whole tree is deleted, you get a single event.
> >> I assume, the same could in theory be true for adding.
> >>
> >> The question is, whether we want to keep this model for the observation
> >> API we're about to implement. Especially as there are some additional
> >> things to consider:
> >>
> >> 1. With Oak we could register observation listener which provide the
> >> information about every node removed/added/changed. So we can send out
> >> detailed events. Other resource provider implementations could simply
> >> follow that concept.
> >
> > One event per resource makes implementing depending systems more
> > straightforward, e.g. adding/removing data for a resource from a search
> index.
>
> While this sounds nice, I guess in practice you can't solely rely on
> observation for this. You might miss events as your listener is
> registered "too late", is updated, uninstalled etc.
>
> > So +1.
> >
> >> 2. We have three events for resources: added/removed/changed but also
> >> two events for resource providers. Obviously, if a resource provider is
> >> mounted at some path and is unregistered, the whole tree is removed.
> >> Again, we just send out a single event.
> >>
> >> For 2. we definitely don't want to send out an event for every resource
> >> of that provider as that would be way too expensive.
> >>
> >> For 1. we might start sending out too many events as well and I assume
> >> code is already prepared for that case.
> >
> > What does that mean? _too_ many for whom? Can we process _too_ many
> events
> > reliable?
> That's a good question - I guess with good filtering by the listener
> registrations we should be able to do so.
>
> >
> >> I think we should keep the optimization (and make this clear in the new
> >> observation API) and we probably should collapse the two special
> >> resource provider events into resource events: instead of sending out a
> >> resource provider added/removed, we send out a resource added/removed.
> >> Listeners right now usually handle all five events, and we could reduce
> >> this to three events, making everything compacter, nicer and easier to
> >> understand.
> >>
> >> WDYT?
> >
> > hm, added/removed resources and added/removed resource providers are
> from some
> > aspects totally different use cases which I think should be seen as such.
>
> It depends on your point of view I think - for someone interested in
> whether a resource has been added or removed, there is no difference
> whether a resource has been removed or the resource provider who
> provided this. It's the same. And observation listeners are interested
> to find out about resource changes, therefore whether something happened
> because of a change in the database or a provider change is not relevant.
>
> > I would like to differ between added/removed resources and added/removed
> > resource providers. But having events for all resources added/removed
> when a
> > resource provider is added/removed is also helpful. -1 for collapsing.
> Can you give some use cases where you want to know about a provider
> being added or removed - in contrast to the resource it provides?
>
> >
> > How rich are these events? Can a listener determine the provider for a
> > resource? Can a listener determine if a resource was added/removed
> because its
> > provider was added/removed? - forgive my ignorance, hadn't time to look
> into
> > the new APIs so far.
>
> The current API is quiet simple - if a provider is added or removed, we
> send out a provider add/remove event with the mount path of the 

[jira] [Commented] (SLING-4135) Make discovery implementation independent from JCR

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-4135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14991698#comment-14991698
 ] 

Stefan Egli commented on SLING-4135:


IIUC then we'd yet have to come to an agreement if/how we'd like to map 
jcr-repository descriptors to the sling resource concept. Is anything already 
ongoing in this area?
Re the move I guess we could switch to SLING-5186 - but that one is not yet 
released.

For both it would mean that it breaks backwards-compatibility .. but I guess 
that's the price to pay?

[~cziegeler], [~bdelacretaz], wdyt?

> Make discovery implementation independent from JCR
> --
>
> Key: SLING-4135
> URL: https://issues.apache.org/jira/browse/SLING-4135
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Carsten Ziegeler
> Fix For: Discovery Impl 1.2.2
>
>
> There are only a few calls to the JCR api - in order to make it completely 
> use just the Sling API these places should be changed to the Sling API as 
> well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [RT] Handling resource (provider) changes

[Carsten Ziegeler]

Am 05.11.15 um 14:01 schrieb Oliver Lietz:
> On Wednesday 04 November 2015 18:45:00 Carsten Ziegeler wrote:
>> The current active model for observation event for resources through
>> OSGi events is modelled after JCR observation which means that for
>> changes to a tree you might only get an event for the root of that tree.
>> Especially when a whole tree is deleted, you get a single event.
>> I assume, the same could in theory be true for adding.
>>
>> The question is, whether we want to keep this model for the observation
>> API we're about to implement. Especially as there are some additional
>> things to consider:
>>
>> 1. With Oak we could register observation listener which provide the
>> information about every node removed/added/changed. So we can send out
>> detailed events. Other resource provider implementations could simply
>> follow that concept.
> 
> One event per resource makes implementing depending systems more 
> straightforward, e.g. adding/removing data for a resource from a search index.

While this sounds nice, I guess in practice you can't solely rely on
observation for this. You might miss events as your listener is
registered "too late", is updated, uninstalled etc.

> So +1.
> 
>> 2. We have three events for resources: added/removed/changed but also
>> two events for resource providers. Obviously, if a resource provider is
>> mounted at some path and is unregistered, the whole tree is removed.
>> Again, we just send out a single event.
>>
>> For 2. we definitely don't want to send out an event for every resource
>> of that provider as that would be way too expensive.
>>
>> For 1. we might start sending out too many events as well and I assume
>> code is already prepared for that case.
> 
> What does that mean? _too_ many for whom? Can we process _too_ many events 
> reliable?
That's a good question - I guess with good filtering by the listener
registrations we should be able to do so.

> 
>> I think we should keep the optimization (and make this clear in the new
>> observation API) and we probably should collapse the two special
>> resource provider events into resource events: instead of sending out a
>> resource provider added/removed, we send out a resource added/removed.
>> Listeners right now usually handle all five events, and we could reduce
>> this to three events, making everything compacter, nicer and easier to
>> understand.
>>
>> WDYT?
> 
> hm, added/removed resources and added/removed resource providers are from 
> some 
> aspects totally different use cases which I think should be seen as such.

It depends on your point of view I think - for someone interested in
whether a resource has been added or removed, there is no difference
whether a resource has been removed or the resource provider who
provided this. It's the same. And observation listeners are interested
to find out about resource changes, therefore whether something happened
because of a change in the database or a provider change is not relevant.

> I would like to differ between added/removed resources and added/removed 
> resource providers. But having events for all resources added/removed when a 
> resource provider is added/removed is also helpful. -1 for collapsing.
Can you give some use cases where you want to know about a provider
being added or removed - in contrast to the resource it provides?

> 
> How rich are these events? Can a listener determine the provider for a 
> resource? Can a listener determine if a resource was added/removed because 
> its 
> provider was added/removed? - forgive my ignorance, hadn't time to look into 
> the new APIs so far.

The current API is quiet simple - if a provider is added or removed, we
send out a provider add/remove event with the mount path of the provider.
For resource change events its the path.

I guess we're actually discussing two totally different things here and
I brought them up in a single discussion :)
1. Whether we send out events for all resources of a delete (add/update)
operation or can optimize as JCR does?
2. How to deal with resource provider changes?

Regards
Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [VOTE] Release Apache Sling IDE Tooling version 1.0.10

[Stefan Egli]

+1

(checked checksums, built project)

just a small note: for me it downloaded both the 1.0.10 and the previous
1.0.8 - perhaps a bug in check_staged_release.sh? but wouldn't block the
vote anyway of course..

Cheers,
Stefan

On 05/11/15 13:39, "Robert Munteanu"  wrote:

>Hi,
>
>We solved 1 issue in this release:
>https://issues.apache.org/jira/browse/SLING/fixforversion/12334041
>
>There are still some outstanding issues:
>https://issues.apache.org/jira/browse/SLING/component/12320908
>
>The release candidate has been uploaded at
>https://dist.apache.org/repos/dist/dev/sling, The release artifact is
>the source bundle - org.apache.sling.ide.source-bundle-1.0.10.zip -
>which can be used to build the project using
>
>mvn clean package
>
>The resulting binaries can be installed into an Eclipse instance from
>the update site which is found at p2update/target/repository after
>building the project.
>
>You can use this UNIX script to download the release and verify the
>signatures:
>http://svn.apache.org/repos/asf/sling/trunk/tooling/ide/check_staged_re
>lease.sh
>
>Usage:
>sh check_staged_release.sh 1.0.10 /tmp/sling-staging
>
>Please vote to approve this release:
>
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
>
>This majority vote is open for at least 72 hours

[jira] [Updated] (SLING-5060) use virtual clock for discovery tests

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-5060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli updated SLING-5060:
---
Fix Version/s: (was: Discovery Impl 1.2.2)

removed fix version for now. this is test-cleanup for later.

alternatively, instead of using fixed thread.sleeps/waits we could also switch 
to waitUntil approach where we wait until a certain condition is hit before we 
continue. this would make the test perform much fast too - but still be 
flexible and stable when running on slower hardware.

> use virtual clock for discovery tests
> -
>
> Key: SLING-5060
> URL: https://issues.apache.org/jira/browse/SLING-5060
> Project: Sling
>  Issue Type: Test
>  Components: Extensions
>Affects Versions: Discovery Impl 1.1.6
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> Currently there are test failures on different CI instances due to the fact 
> that they sometimes run rather slow vs what is expected during tests. This 
> badly affects test stability.
> An alternative to always increase the timing further and further whenever a 
> test failure is encountered, is to use a virtual clock instead. This would 
> allow to make very precise tests in a very fast manner.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)