[jira] [Closed] (SLING-4886) Testing tools bundles installer fails if there are no bundles to install

[Stefan Seifert (JIRA)]

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

Stefan Seifert closed SLING-4886.
-

> Testing tools bundles installer fails if there are no bundles to install
> 
>
> Key: SLING-4886
> URL: https://issues.apache.org/jira/browse/SLING-4886
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: org.apache.sling.testing.tools 1.0.10
>Reporter: Satya Deep Maheshwari
>Assignee: Konrad Windszus
>Priority: Minor
> Fix For: org.apache.sling.testing.tools 1.0.12
>
> Attachments: SLING-4886.patch
>
>
> Background:
> org.apache.sling.testing.tools.sling.BundlesInstaller.installBundles is 
> invoked by 
> org.apache.sling.testing.tools.sling.SlingTestBase.installAdditionalBundles 
> for installing any additional bundles which may be necessary while running a 
> test sling instance for some integration tests.
> Problem:
> The problem with BundlesInstaller.installBundles is that it fails if there 
> are no bundles to install and hence the integration tests fail. 
> Expectation:
> BundlesInstaller.installBundles should not fail if there are no bundles to 
> install. It should just be a no-op.
> Fix:
> The problem is with a log message in this method which assumes that the 
> bundles list will not be empty. Also the log text seems to incorrectly assume 
> that the list contains bundles' folder path while it actually contains the 
> bundle list.



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

[jira] [Closed] (SLING-4819) Allow to automatically undeploy all deployed bundles after execution of ITs

[Stefan Seifert (JIRA)]

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

Stefan Seifert closed SLING-4819.
-

> Allow to automatically undeploy all deployed bundles after execution of ITs
> ---
>
> Key: SLING-4819
> URL: https://issues.apache.org/jira/browse/SLING-4819
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: org.apache.sling.testing.tools 1.0.10
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: JUnit Remote Test Runners 1.0.12, 
> org.apache.sling.testing.tools 1.0.12
>
> Attachments: SLING-4819-combined.patch, 
> SLING-4819-junitremote-v01.diff, SLING-4819-testingtools-v01.diff
>
>
> Through the property {{sling.additional.bundle}} it is already possible to 
> deploy bundles before running integration tests derived from 
> {{SlingTestBase}}.
> It should also be supported to automatically undeploy those bundles after the 
> test has finished.



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

[jira] [Closed] (SLING-4838) Tests failing if "test.server.url" is not null but blank

[Stefan Seifert (JIRA)]

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

Stefan Seifert closed SLING-4838.
-

> Tests failing if "test.server.url" is not null but blank
> 
>
> Key: SLING-4838
> URL: https://issues.apache.org/jira/browse/SLING-4838
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: org.apache.sling.testing.tools 1.0.10
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Fix For: org.apache.sling.testing.tools 1.0.12
>
>
> In SlingTestBase there is a check for whether the system property 
> {{test.server.url}} is set or not. It only checks for null but does not take 
> into account that it could be blank.
> This leads to integration test failures on Jenkins.



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

[jira] [Closed] (SLING-3873) Using SlingTestBase does not work with a non-standard password set on the sling server

[Stefan Seifert (JIRA)]

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

Stefan Seifert closed SLING-3873.
-

> Using SlingTestBase does not work with a non-standard password set on the 
> sling server
> --
>
> Key: SLING-3873
> URL: https://issues.apache.org/jira/browse/SLING-3873
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: org.apache.sling.testing.tools 1.0.6
>Reporter: Kapil V Ahuja
>Assignee: Robert Munteanu
>Priority: Critical
> Fix For: org.apache.sling.testing.tools 1.0.12
>
>
> I was using SlingTestBase class and was trying to run the tests against a 
> hosted CQ server. I am not using a standard "Admin/admin" username/password 
> and the base class was not initializing. Upon debugging the code, i noticed 
> the following potential bug (unless you can tell me how to override this).
> {code:title="WebConcoleClient.java"}
> public void checkBundleInstalled(String symbolicName, int timeoutSeconds) 
> {
> final String path = getBundlePath(symbolicName, ".json");
> new RetryingContentChecker(executor, builder).check(path, 200, 
> timeoutSeconds, 500);
> }
> {code}
> Note that this class is calling the RetryingContentChecker without a username 
> and password. This calls the constructor as follows
> {code:title="RetryingContentChecker.java"}
> public RetryingContentChecker(RequestExecutor executor, RequestBuilder 
> builder) {
> this(executor, builder, null, SlingTestBase.ADMIN);
> }
> public RetryingContentChecker(RequestExecutor executor, RequestBuilder 
> builder, String username, String password) {
> this.executor = executor;
> this.builder = builder;
> if (username != null) {
> this.username = username;
> } else {
> this.username = SlingTestBase.ADMIN;
> }
> if (password != null) {
> this.password = password;
> } else {
> this.password = SlingTestBase.ADMIN;
> }
> }
> {code}
> I you read the logic, even though I have passed my password in system 
> properties, the default password "Admin" gets set and the connection to my 
> hosted server doesnt work and this fails for me. 
> I really need this to be fixed and may try to provide a patch, but i need to 
> know if i invest the time to setup the development environment on my local 
> machine - checkout, compile, pass test cases, understand how the lifecycle 
> works for you, how soon can a patch build be released to maven repository so 
> that i can use that JAR. If that's not going to happen soon, i will just 
> override classes locally for now. 
> thanks



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

[jira] [Updated] (SLING-5371) JcrInstaller should not listen on / for moves

[Marc Pfaff (JIRA)]

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

Marc Pfaff updated SLING-5371:
--
Attachment: SLING_5371_fixing_testclass.patch

> JcrInstaller should not listen on / for moves
> -
>
> Key: SLING-5371
> URL: https://issues.apache.org/jira/browse/SLING-5371
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Reporter: Marc Pfaff
>Assignee: Bertrand Delacretaz
> Attachments: SLING_5371.patch, SLING_5371_fixing_testclass.patch, 
> SLING_5371_jackrabbit.patch, SLING_5371_jcr_only.patch
>
>
> The JcrInstaller is currently registering a JCR listener for move events on 
> the root node with setting the 'deep' property to true. If it comes to 
> processing the underlaying Oak observation queue, this combination is very 
> inefficient, as it does not allow Oak to filter changes by path. 
> AFAIU this move listener is covering the use case where an installer artifact 
> is moved from/to an installer root folder. I therefore wanted to propose to 
> register the move listener on the configured root folders only.  



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

[RESULT] [VOTE] Release Apache Sling Testing Tools 1.0.12

[Stefan Seifert]

Hi,

The vote has passed with the following result :

+1 (binding): Stefan Seifert, Robert Munteanu, Carsten Ziegeler

I will copy this release to the Sling dist directory and
promote the artifacts to the central Maven repository.


stefan

[jira] [Commented] (SLING-5371) JcrInstaller should not listen on / for moves

[Marc Pfaff (JIRA)]

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

Marc Pfaff commented on SLING-5371:
---

Hi [~bdelacretaz]. Sorry for the late reply. I think I figured what's wrong 
with the RootFolderMoveListenerTest.testMove() test. The RootFolderMoveListener 
is registered with the noLocal property set to true. But for the test class we 
use the same session for registering the RootFolderMoveListener and for 
performing the content move. Because noLocal is set to true no observations are 
delivered to the RootFolderMoveListener. 

I refactored the test a little bit to use 2 sessions, one for registering the 
listener and one to perform the move, and now the test is passing fine for me. 
Please see patch SLING_5371_fixing_testclass.patch.  

> JcrInstaller should not listen on / for moves
> -
>
> Key: SLING-5371
> URL: https://issues.apache.org/jira/browse/SLING-5371
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Reporter: Marc Pfaff
>Assignee: Bertrand Delacretaz
> Attachments: SLING_5371.patch, SLING_5371_fixing_testclass.patch, 
> SLING_5371_jackrabbit.patch, SLING_5371_jcr_only.patch
>
>
> The JcrInstaller is currently registering a JCR listener for move events on 
> the root node with setting the 'deep' property to true. If it comes to 
> processing the underlaying Oak observation queue, this combination is very 
> inefficient, as it does not allow Oak to filter changes by path. 
> AFAIU this move listener is covering the use case where an installer artifact 
> is moved from/to an installer root folder. I therefore wanted to propose to 
> register the move listener on the configured root folders only.  



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

[jira] [Commented] (SLING-5463) GetStarTest fails with "Invalid name or path"

[Joel Richard (JIRA)]

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

Joel Richard commented on SLING-5463:
-

[~cziegeler], that's correct. The idea of my approach was to handle all cases 
which would lead to a RepositoryException in itemExists before getItemOrNull is 
even called. Unfortunately, that seems impossible without using a session 
specific isValidPath() method because there can be different 
org.apache.jackrabbit.oak.namepath.NamePathMapper implementations. Moreover, 
the existing NamePathMapperImpl#getOakPath is already quite complex.

> GetStarTest fails with "Invalid name or path"
> -
>
> Key: SLING-5463
> URL: https://issues.apache.org/jira/browse/SLING-5463
> Project: Sling
>  Issue Type: Bug
>  Components: JCR, Testing
>Reporter: Bertrand Delacretaz
>Assignee: Robert Munteanu
>  Labels: sling-IT
> Fix For: JCR Resource 2.6.0
>
>
> The GetStarTest from launchpad/integration-tests recently started failing, 
> for example at [1]:
> {code}
> javax.jcr.RepositoryException: Invalid name or path: 
> /GetStarTest1453972215267/* 
>  at 
> org.apache.jackrabbit.oak.jcr.session.SessionContext.getOakPathOrThrow(SessionContext.java:347)
> ...
>  at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.getItemOrNull(SessionImpl.java:225)
>  at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrItemResourceFactory.getItemOrNull(JcrItemResourceFactory.java:182)
>  at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrItemResourceFactory.createResource(JcrItemResourceFactory.java:96)
>  at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.listChildren(JcrResourceProvider.java:293)
>  at 
> org.apache.sling.resourceresolver.impl.providers.stateful.AuthenticatedResourceProvider.listChildren(AuthenticatedResourceProvider.java:175)
>  at 
> org.apache.sling.resourceresolver.impl.providers.stateful.CombinedResourceProvider.listChildren(CombinedResourceProvider.java:205)
>  at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.listChildren(ResourceResolverImpl.java:719)
>  at 
> org.apache.sling.api.resource.ResourceUtil.listChildren(ResourceUtil.java:360)
> ...
>  at 
> org.apache.sling.servlets.get.impl.helpers.JsonRendererServlet.doGet(JsonRendererServlet.java:100)
> {code}
> [1] 
> https://builds.apache.org/view/S-Z/view/Sling/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.launchpad.testing/3252/testReport/junit/org.apache.sling.launchpad.webapp.integrationtest/GetStarTest/testGetStarJson/



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

[jira] [Commented] (SLING-5435) Decouple processes that depend on cluster leader elections from the cluster leader elections.

[Timothee Maret (JIRA)]

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

Timothee Maret commented on SLING-5435:
---

Using a broken example was probably not making things clearer :-) I could help 
with a patch (API) unless someone wants to tackle this. For discovery 
implementations to support that new API, I would open separate issues.

> Decouple processes that depend on cluster leader elections from the cluster 
> leader elections.
> -
>
> Key: SLING-5435
> URL: https://issues.apache.org/jira/browse/SLING-5435
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Reporter: Ian Boston
>
> Currently there are many processes in Sling that must complete before a Sling 
> Discovery cluster leader election is declared complete. These processes 
> include things like transferring all Jobs from the old leader to the new 
> leader and waiting for the data to appear visible on the new leader. This 
> introduces an additional overhead to the leader election process which 
> introduces a higher than desirable timeout for elections and heartbeat. This 
> higher than desirable timeout precludes the use of more efficient election 
> and distributed consensus algorithms as implemented in Etcd, Zookeeper or 
> implementations of RAFT.
> If the election could be declared complete leaving individual components to 
> manage their own post election operations (ie decoupling those processes from 
> the election), then faster election or alternative Discovery implementations 
> such as the one implemented on etcd could be used.



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

Re: SLING-5421 - Allow JCR installer to recover from being paused indefinitely

[Julian Sedding]

Hi Carsten

There are two things to consider:

(1) moving the implementation of the repository based signalling into
the installer (essentially encapsulation)
(2) implementation of a robust protocol for signalling a block to
installers on other cluster nodes

So far I have talked about (1) but didn't go into the details of (2).
What I have in mind for (2) is a content structure that records three
pieces of information information:

- Sling ID in order to identify on which cluster node the block was triggered
- Service PID (i.e. the fully qualified class name of the
implementation) in order to know which service triggered the block
- Creation timestamp for information/debugging

The content structure would look like the following:

/system/sling/installer/jcr/pauseInstallation
/
/
/
jcr:created = 

It is important that, as a general rule, any node without children is
eagerly deleted. This means that the installer is blocked if
"pauseInstallation" has at least one child node and unblocked if it
has none (or does not exist itself).

The structure would allow a single service to hold multiple blocks
(each  node representing one).

Normally we would assume that a service blocks the installer and later
unblocks it again, ideally using a try/finally block. However, it gets
interesting when edge cases are considered:
- the repository service may get stopped (or restarted), in which case
the unblock can fail
- a cluster node can be killed or disconnected before the unblock can be done
- I have seen log files where the "blocking" service was restarted
while it blocked the installer, because the installer was
asynchronously processing a batch from a previous block. However, it
is unclear why the unblock did not happen in this case: there were no
exceptions in the log and I don't believe they were swallowed, because
 when I provoked a similar scenario exceptions were written to the
log.

To recover from such failure scenarios, the installer needs to be unblocked:
- if a blocking service is stopped. A stopped service may still exist
in the JVM and finish execution, therefore this could be solved using
weak references to a block-token and a reference queue. Or
alternatively by using a timeout in such cases.
- if a cluster node disappears from a topology, its  node
should be removed after a timeout

There is a danger, however, that unblocking the installer due to
recovery causes a partial deployment to be installed. This may put the
system into an unusable state (e.g. bundles may not be resolvable,
because their dependencies were not updated(installed). I don't know
how we could address this.

Maybe an entirely different approach would be to provide a list of
deployables (e.g. repository paths?) to the installer, which then only
installs the deployables if all are available (ignoring deployables
with extensions it does not handle). This list would need to be
communicated in a cluster as well, however.

Regards
Julian


On Sun, Jan 31, 2016 at 10:34 AM, Carsten Ziegeler  wrote:
> Julian Sedding wrote
>> Hi Carsten
>>
>>> Offline discussions don't make it transparent why you came to this
>>> conclusion.
>>> Please enclose the relevant information either here or in the issue.
>>
>> Sure, I thought that I included some information both in the email and
>> in the issue. But it is probably worthwhile to expand on it a bit
>> more.
>>
>> The current implementation is based on a convention rather than a
>> contract: place a node under a specific parent node and the JCR
>> installer will pause its activities.
>>
>> It turns out that this convention in this simple form has limitations
>> when things go wrong:
>>
>> - If a "deployer" implementation fails to delete the pause-marker node
>> (no matter what the reasons are), whose responsibility is it to delete
>> this node to recover the system?
>> - If a "deployer" on cluster node A creates a pause-marker node and
>> then cluster node A is shut down/crashes/disconnects, whose
>> responsibility is it to delete this node to recover the system?
>>
>> Both these questions require a more sophisticated convention IMHO.
>> This becomes a burden for implementers, makes fixing the convention
>> nearly impossible (in case we miss an edge case) and is brittle,
>> because "deployers" may have bugs in their implementations.
>>
>> So the logical conclusion is to move the implementation of this
>> "convention" into Sling and expose it via a simple API.
>>
>> The convention basically becomes an implementation detail, which is
>> needed to distribute the information about blocking the installer
>> within a cluster.
>>
>> Does this answer your questions?
>>
>
> Thanks, yes, however :) I can't follow the conclusion. How is having an
> API which for example has a pause/resume method to be called
> different/easier/avoiding the problems than adding/removing a node?
>
> Carsten
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> 

[RESULT][VOTE] Release Apache Sling discovery.commons 1.0.10 and discovery.oak 1.2.4

[Stefan Egli]

The vote passed with 3 binding results. I'll do the remaining bits next.

Cheers,
Stefan

On 28/01/16 14:51, "Stefan Egli"  wrote:

>Hi,
>
>For the following two releases we solved:
>
>
>Discovery.commons 1.0.10 (replacing dropped 1.0.8)
>- 1 issue of dropped 1.0.8:
>  https://issues.apache.org/jira/browse/SLING/fixforversion/12334212
>- 1 regression issue in 1.0.10:
>  https://issues.apache.org/jira/browse/SLING/fixforversion/12334746
>
>
>
>Discovery.oak 1.2.4 (replacing dropped 1.2.2)
>- 2 issues of dropped 1.2.2:
>  https://issues.apache.org/jira/browse/SLING/fixforversion/12334214
>- 0 issues in 1.2.4 (except upped pom dependency to discovery.commons
>1.0.10)
>  https://issues.apache.org/jira/browse/SLING/fixforversion/12334743
>
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-1413/
>
>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 1413 /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] [Updated] (SLING-5471) Sightly error in terminal: RHINO USAGE WARNING: Missed Context.javaToJS() conversion

[Joel Richard (JIRA)]

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

Joel Richard updated SLING-5471:

Component/s: (was: Extensions)
 Scripting

> Sightly error in terminal: RHINO USAGE WARNING: Missed Context.javaToJS() 
> conversion
> 
>
> Key: SLING-5471
> URL: https://issues.apache.org/jira/browse/SLING-5471
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.10
> Environment: Mac
>Reporter: Joel Richard
>
> I often see the following error in the terminal:
> {code}
> RHINO USAGE WARNING: Missed Context.javaToJS() conversion:
> Rhino runtime detected object 
> java.util.GregorianCalendar[time=1434664044399,areFieldsSet=true,areAllFieldsSet=true,lenient=false,zone=sun.util.calendar.ZoneInfo[id="GMT-07:00",offset=-2520,dstSavings=0,useDaylight=false,transitions=0,lastRule=null],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2015,MONTH=5,WEEK_OF_YEAR=25,WEEK_OF_MONTH=3,DAY_OF_MONTH=18,DAY_OF_YEAR=169,DAY_OF_WEEK=5,DAY_OF_WEEK_IN_MONTH=3,AM_PM=1,HOUR=2,HOUR_OF_DAY=14,MINUTE=47,SECOND=24,MILLISECOND=399,ZONE_OFFSET=-2520,DST_OFFSET=0]
>  of class java.util.GregorianCalendar where it expected String, Number, 
> Boolean or Scriptable instance. Please check your code for missing 
> Context.javaToJS() call.
> {code}
> I think it happens for if statements. Attached is a stack. Please let me know 
> if you need more information.



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

[jira] [Commented] (SLING-5435) Decouple processes that depend on cluster leader elections from the cluster leader elections.

[Stefan Egli (JIRA)]

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

Stefan Egli commented on SLING-5435:


[~cziegeler], re
bq. It might happen that the old leader did a change, which the new leader 
doesn't see yet and therefore the new leader might try a similar operation
That was the original thinking behind doing the sync, yes.

A certain class of TopologyEventListeners (such as for example job handling) 
can be written in a way that is resilient to repository delays. Namely by 
forcing a 'repository sync' for a particular node by making a change that 
forces a conflict even if old leader changes are delayed.

However, I think that this is not possible for all cases - ignoring the fact 
that when writing a TopologyEventListener you might not be aware of these 
subleties. 

Additionally though, there might be 'derivative cases' - such as for example 
the Sling Scheduler - which only check the 'leader' flag to then behave 
leader-like or not. What that 'leader-like' implies is unclear and can perhaps 
not always be 'guarded' via a repository-synched flag (which tries to result in 
a conflict in these delay-cases).

I think it helps the default implementor of TopologyEventListener writing 
leader-failover-stable code when it receives the TOPOLOGY_CHANGED only after a 
repo-sync. Leaving this to each and every listener implementor might result in 
duplication of code as well as less stable code..

[~marett], re
bq. For those use cases, with the given discovery API and implementations, it 
is already possible to avoid the delay by polling the DiscoveryService instead 
of handling the TopologyEventListener events. However, I believe it is a rather 
discouraged thing.

I disagree. You cannot poll DiscoveryService to get {{isCurrent}} true *before* 
the TopologyEventListeners get informed. In fact, these two things are coupled: 
{{TopologyView.isCurrent()}} and the {{TOPOLOGY_CHANGED}} event are 
synchronized. That is, {{isCurrent()}} only returns true once discovery starts 
sending out {{TOPOLOGY_CHANGED}} events. 

bq. LEADER_CHANGED
Some comments that come to mind:
* Alternative suggestion for the name: {{TOPOLOGY_CHANGED_UNSYNCHED}}
* If we introduce this event, it would have to be kept backwards-compatible, ie 
after this event you'd also must get a {{TOPOLOGY_CHANGED}} event.
* I still see the risk of breaking client code with this, as some might do 
things like "{{if (event.getType() != TOPOLOGY_CHANGING){}}}" or similar - in 
which case the new event type might result in execution where that was not 
intended..
* We should think about how we could keep the API symmetric: currently there 
are two fully equivalent variants: polling via 
{{DiscoveryService.getTopology()}} or push via {{TopologyEventListener}}. The 
new event is so far only available via push.
* If we do it the other way, by making this a property of 
{{TopologyEventListener}} ("{{unsynchronized=true}}"), we make it more 
backwards compatible, as only those listeners are affected that set this 
property. However it would still result in an asymmetric API and I think we 
should do something about it in both cases.
* Perhaps one possibility for providing this info in the poll variant could be: 
{{getUnsynchronizedTopology()}}. (sounds somewhat ugly though..)

Overall I tend to think that going via a listener property introduces less 
friction, but a new event type would certainly also be possible...

> Decouple processes that depend on cluster leader elections from the cluster 
> leader elections.
> -
>
> Key: SLING-5435
> URL: https://issues.apache.org/jira/browse/SLING-5435
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Reporter: Ian Boston
>
> Currently there are many processes in Sling that must complete before a Sling 
> Discovery cluster leader election is declared complete. These processes 
> include things like transferring all Jobs from the old leader to the new 
> leader and waiting for the data to appear visible on the new leader. This 
> introduces an additional overhead to the leader election process which 
> introduces a higher than desirable timeout for elections and heartbeat. This 
> higher than desirable timeout precludes the use of more efficient election 
> and distributed consensus algorithms as implemented in Etcd, Zookeeper or 
> implementations of RAFT.
> If the election could be declared complete leaving individual components to 
> manage their own post election operations (ie decoupling those processes from 
> the election), then faster election or alternative Discovery implementations 
> such as the one implemented on etcd could be used.



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

[jira] [Created] (SLING-5471) Sightly error in terminal: RHINO USAGE WARNING: Missed Context.javaToJS() conversion

[Joel Richard (JIRA)]

Joel Richard created SLING-5471:
---

 Summary: Sightly error in terminal: RHINO USAGE WARNING: Missed 
Context.javaToJS() conversion
 Key: SLING-5471
 URL: https://issues.apache.org/jira/browse/SLING-5471
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Scripting Sightly Engine 1.0.10
 Environment: Mac
Reporter: Joel Richard


I often see the following error in the terminal:

{code}
RHINO USAGE WARNING: Missed Context.javaToJS() conversion:
Rhino runtime detected object 
java.util.GregorianCalendar[time=1434664044399,areFieldsSet=true,areAllFieldsSet=true,lenient=false,zone=sun.util.calendar.ZoneInfo[id="GMT-07:00",offset=-2520,dstSavings=0,useDaylight=false,transitions=0,lastRule=null],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2015,MONTH=5,WEEK_OF_YEAR=25,WEEK_OF_MONTH=3,DAY_OF_MONTH=18,DAY_OF_YEAR=169,DAY_OF_WEEK=5,DAY_OF_WEEK_IN_MONTH=3,AM_PM=1,HOUR=2,HOUR_OF_DAY=14,MINUTE=47,SECOND=24,MILLISECOND=399,ZONE_OFFSET=-2520,DST_OFFSET=0]
 of class java.util.GregorianCalendar where it expected String, Number, Boolean 
or Scriptable instance. Please check your code for missing Context.javaToJS() 
call.
{code}

I think it happens for if statements. Attached is a stack. Please let me know 
if you need more information.



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

[jira] [Updated] (SLING-5471) Sightly error in terminal: RHINO USAGE WARNING: Missed Context.javaToJS() conversion

[Joel Richard (JIRA)]

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

Joel Richard updated SLING-5471:

Attachment: Screen Shot 2016-02-01 at 11.14.07.png

> Sightly error in terminal: RHINO USAGE WARNING: Missed Context.javaToJS() 
> conversion
> 
>
> Key: SLING-5471
> URL: https://issues.apache.org/jira/browse/SLING-5471
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.10
> Environment: Mac
>Reporter: Joel Richard
> Attachments: Screen Shot 2016-02-01 at 11.14.07.png
>
>
> I often see the following error in the terminal:
> {code}
> RHINO USAGE WARNING: Missed Context.javaToJS() conversion:
> Rhino runtime detected object 
> java.util.GregorianCalendar[time=1434664044399,areFieldsSet=true,areAllFieldsSet=true,lenient=false,zone=sun.util.calendar.ZoneInfo[id="GMT-07:00",offset=-2520,dstSavings=0,useDaylight=false,transitions=0,lastRule=null],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2015,MONTH=5,WEEK_OF_YEAR=25,WEEK_OF_MONTH=3,DAY_OF_MONTH=18,DAY_OF_YEAR=169,DAY_OF_WEEK=5,DAY_OF_WEEK_IN_MONTH=3,AM_PM=1,HOUR=2,HOUR_OF_DAY=14,MINUTE=47,SECOND=24,MILLISECOND=399,ZONE_OFFSET=-2520,DST_OFFSET=0]
>  of class java.util.GregorianCalendar where it expected String, Number, 
> Boolean or Scriptable instance. Please check your code for missing 
> Context.javaToJS() call.
> {code}
> I think it happens for if statements. Attached is a stack. Please let me know 
> if you need more information.



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

[jira] [Commented] (SLING-5421) Allow JCR installer to recover from being paused indefinitely

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-5421:


If an API is created for this it can probably be made generic, in the end it's 
just a shared boolean flag with a time to live.

> Allow JCR installer to recover from being paused indefinitely
> -
>
> Key: SLING-5421
> URL: https://issues.apache.org/jira/browse/SLING-5421
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Affects Versions: JCR Installer 3.1.8
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: JCR Installer 3.1.18
>
>
> With SLING-3747 the JCR installer provided a mechanism for pausing the 
> installer to support cases where installation can result in restart of 
> installer bundle itself.
> However it may happen that once this flag is set the process gets abruptly 
> killed and the flag remain set. In such a case the installer would remain 
> paused and a user would have to remove the flag for it to work again. To 
> support such cases there should be some kind of timeout such that installer 
> does not remain in pause state forever.
> Note also the [discussion on the 
> mailinglist|http://markmail.org/thread/dlutannhyrk55h43].



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

[jira] [Created] (SLING-5472) Some distribution packages are leaked because delete is called on closed objects

[Marius Petria (JIRA)]

Marius Petria created SLING-5472:


 Summary: Some distribution packages are leaked because delete is 
called on closed objects
 Key: SLING-5472
 URL: https://issues.apache.org/jira/browse/SLING-5472
 Project: Sling
  Issue Type: Bug
  Components: Distribution
Reporter: Marius Petria
Assignee: Marius Petria
 Fix For: Content Distribution Core 0.1.14






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

[jira] [Resolved] (SLING-5472) Some distribution packages are leaked because delete is called on closed objects

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5472.
--
Resolution: Fixed

Committed revision 1727938.


> Some distribution packages are leaked because delete is called on closed 
> objects
> 
>
> Key: SLING-5472
> URL: https://issues.apache.org/jira/browse/SLING-5472
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.14
>
>




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

Re: Utility to construct paths out of strings?

[Bertrand Delacretaz]

Hi,

On Mon, Feb 1, 2016 at 1:56 PM, Robert Munteanu  wrote:
> ...we re-re-opened the issue :-) and are leaning towards
> moving the class back in the api bundle, in a different package..

That works for me, if it's a different package it's fine.

-Bertrand

Re: Utility to construct paths out of strings?

[Robert Munteanu]

On Wed, 2016-01-27 at 16:02 +0200, Robert Munteanu wrote:
> On Tue, 2016-01-26 at 18:06 +0200, Robert Munteanu wrote:
> > On Tue, 2016-01-26 at 16:15 +0100, Bertrand Delacretaz wrote:
> > > Hi Robert,
> > > 
> > > > ...
> > > >   https://issues.apache.org/jira/browse/SLING-5455
> > > >   https://svn.apache.org/r1726814 ...
> > > 
> > > I have second thoughts about this, sorry ;-)
> > > 
> > > Touching our "sacred" API bundle just for this doesn't feel
> > > right...how about creating a new bundles/extensions/sling-commons
> > > or
> > > sling-util bundle? It will be almost empty for now but that's a
> > > good
> > > place to add such minor utilities later, without touching
> > > "important"
> > > bundles.
> > 
> > Moving out of API is fine for me.
> > 
> > Keeping in mind that this will be used by the resourceresolver
> > bundle,
> > is bundles/extensions the right place ? ( not a rhetorical
> > question,
> > I
> > really don't know ).
> > 
> > As for the bundle name, I'm not a very big fan of commons/util
> > since
> > they tend to become onfocused, but I don't have a better idea right
> > now.
> > 
> > I've reopened SLING-5455 to track the creation of the new bundle.
> 
> I've moved the PathBuilder class to a new org.apache.sling.commons
> bundle under bundles/extensions ( maybe it should be under
> bundles/commons, since it does not depend on Sling at all? )
> 
>   https://svn.apache.org/r1727058
> 
> I'll start a release vote early on Friday since I would like to
> release
> next week the resource resolver bundle ( and other which contain the
> work for the new API ).

For the record, we re-re-opened the issue :-) and are leaning towards
moving the class back in the api bundle, in a different package ( so
it's easy to split out into a different bundle, if we decide to do so
in the future ). 

Any arguments against this would be appreciated soon :-)

Thanks,

Robert

> 
> Thanks,
> 
> Robert
> 
> 
> > 
> > Robert
> > 
> > > 
> > > WDYT?
> > > 
> > > -Bertrand
> > 
> 

Re: SLING-5421 - Allow JCR installer to recover from being paused indefinitely

[Carsten Ziegeler]

Julian Sedding wrote
> Hi Carsten
> 
> Thanks for your comments. I agree that it would be nice if we could
> avoid pausing the installer altogether.

If I remember correctly, that's what we said when we added the current
pausing solution: this pausing solution is temporary until we change the
package installer to use the OSGi installer :)

> 
> However, I see some challenges:
> - How do we make sure all nodes in a cluster install the bundles into
> their OSGi environments in a single batch?

Ok, good point - right. Well if a content package would be installed
with a single save this would be easy :)

> - Currently content packages contain bundles that are installed into
> the repository. How could we prevent duplicate installation (by the
> JCR installer triggered via observation and directly by the OSGi
> installer)?

If the content package would be installed through the installer,
the bundles would still be installed through observation. But due to the
single thread after all content is installed.

> 
> Do you think it is realistic to solve these issues in the short term?

Not sure, however changing the mechanism as suggested doesn't sound so
easy to me either.
> 
> Even if we can solve them, we will still need reliable
> communication/coordination between cluster nodes. This part, as
> Bertrand suggested in the issue, could be made generic. AFAIK
> ZooKeeper, etcd et al. provide such mechanisms. Maybe we need to
> provide an implementation agnostic API for this in the discovery
> module.

Well, a lot of things are doable - but starting at the real problem and
ending up with such a massive solution spreading across bundles/apis
doesn't sound appealing to me. I would rather spent the energy and think
about what is the best way to update an installation and derive a
possible solution from there. Especially with containers like docker
instances are not updated but simply a new instance with the new
configuration is started. Therefore I'm wondering if we should really go
this far and add all these things all over the place.

I think for now, the immediate issue to resolve is to recover from being
paused indefinitely. Simplest solution is to require clients to add a
timestamp to the node they create and the node will be removed after a
(long) timeout.

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

[jira] [Updated] (SLING-5474) [HApi] Move sightly use objects to a different package

[Andrei Dulvac (JIRA)]

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

Andrei Dulvac updated SLING-5474:
-
Attachment: SLING-5474.diff

Attached patch, can be applied with {{patch -p0 -i SLING-5474.diff}}

> [HApi] Move sightly use objects to a different package
> --
>
> Key: SLING-5474
> URL: https://issues.apache.org/jira/browse/SLING-5474
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Andrei Dulvac
>  Labels: hapi
> Attachments: SLING-5474.diff
>
>
> Move HApiUse and TypeView use objects to the {{sightly}} sub-package



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

[jira] [Commented] (SLING-5474) [HApi] Move sightly use objects to a different package

[Andrei Dulvac (JIRA)]

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

Andrei Dulvac commented on SLING-5474:
--

[~cziegeler], could you review?

> [HApi] Move sightly use objects to a different package
> --
>
> Key: SLING-5474
> URL: https://issues.apache.org/jira/browse/SLING-5474
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Andrei Dulvac
>  Labels: hapi
> Attachments: SLING-5474.diff
>
>
> Move HApiUse and TypeView use objects to the {{sightly}} sub-package



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

[jira] [Updated] (SLING-4513) Donation proposal of HApi tools

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-4513:

Fix Version/s: HApi 1.0.0

> Donation proposal of HApi tools 
> 
>
> Key: SLING-4513
> URL: https://issues.apache.org/jira/browse/SLING-4513
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Reporter: Andrei Dulvac
>Assignee: Bertrand Delacretaz
>  Labels: PatchAvailable, hapi, scripting
> Fix For: HApi 1.0.0
>
> Attachments: hapi.tar.gz
>
>
> Tracks the donation of HApi tools from https://github.com/dulvac/hapi as a 
> contrib



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

[jira] [Updated] (SLING-5055) [HApi] Potential infinite recursion on reading hapi type from a path

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-5055:

Fix Version/s: HApi 1.0.0

> [HApi] Potential infinite recursion on reading hapi type from a path
> 
>
> Key: SLING-5055
> URL: https://issues.apache.org/jira/browse/SLING-5055
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Andrei Dulvac
>Assignee: Bertrand Delacretaz
>  Labels: PatchAvailable
> Fix For: HApi 1.0.0
>
> Attachments: SLING-5055.patch
>
>
> The Hypermedia API tools could potentially enter an infinite recursion if a 
> type defined in the sling repository has a property of the same type as the 
> type being read.
> The problem is in HApiUtilImpl and the solution I found was to use the types 
> cache before adding the parent and properties.



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

[jira] [Updated] (SLING-5136) [HApi] Add java HApi microdata client

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-5136:

Fix Version/s: HApi 1.0.0

> [HApi] Add java HApi microdata client
> -
>
> Key: SLING-5136
> URL: https://issues.apache.org/jira/browse/SLING-5136
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Andrei Dulvac
>Assignee: Bertrand Delacretaz
>Priority: Minor
>  Labels: PatchAvailable
> Fix For: HApi 1.0.0
>
> Attachments: SLING-5136.git.2.diff, SLING-5136.git.diff
>
>
> The hapi tools extension could make use of a java HTML and microdata client 
> to consume html markup annotated using HApi.



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

[jira] [Resolved] (SLING-5474) [HApi] Move sightly use objects to a different package

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-5474.
-
Resolution: Fixed

Thanks for your patch Andrei, it's applied

> [HApi] Move sightly use objects to a different package
> --
>
> Key: SLING-5474
> URL: https://issues.apache.org/jira/browse/SLING-5474
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Andrei Dulvac
>Assignee: Carsten Ziegeler
>  Labels: hapi
> Fix For: HApi 1.0.0
>
> Attachments: SLING-5474.diff
>
>
> Move HApiUse and TypeView use objects to the {{sightly}} sub-package



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

[jira] [Commented] (SLING-5463) GetStarTest fails with "Invalid name or path"

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-5463:
-

I think to be consistent with the JR 2 implementation, we could use Robert's 
approach as a start

> GetStarTest fails with "Invalid name or path"
> -
>
> Key: SLING-5463
> URL: https://issues.apache.org/jira/browse/SLING-5463
> Project: Sling
>  Issue Type: Bug
>  Components: JCR, Testing
>Reporter: Bertrand Delacretaz
>Assignee: Robert Munteanu
>  Labels: sling-IT
> Fix For: JCR Resource 2.6.0
>
>
> The GetStarTest from launchpad/integration-tests recently started failing, 
> for example at [1]:
> {code}
> javax.jcr.RepositoryException: Invalid name or path: 
> /GetStarTest1453972215267/* 
>  at 
> org.apache.jackrabbit.oak.jcr.session.SessionContext.getOakPathOrThrow(SessionContext.java:347)
> ...
>  at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.getItemOrNull(SessionImpl.java:225)
>  at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrItemResourceFactory.getItemOrNull(JcrItemResourceFactory.java:182)
>  at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrItemResourceFactory.createResource(JcrItemResourceFactory.java:96)
>  at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.listChildren(JcrResourceProvider.java:293)
>  at 
> org.apache.sling.resourceresolver.impl.providers.stateful.AuthenticatedResourceProvider.listChildren(AuthenticatedResourceProvider.java:175)
>  at 
> org.apache.sling.resourceresolver.impl.providers.stateful.CombinedResourceProvider.listChildren(CombinedResourceProvider.java:205)
>  at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.listChildren(ResourceResolverImpl.java:719)
>  at 
> org.apache.sling.api.resource.ResourceUtil.listChildren(ResourceUtil.java:360)
> ...
>  at 
> org.apache.sling.servlets.get.impl.helpers.JsonRendererServlet.doGet(JsonRendererServlet.java:100)
> {code}
> [1] 
> https://builds.apache.org/view/S-Z/view/Sling/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.launchpad.testing/3252/testReport/junit/org.apache.sling.launchpad.webapp.integrationtest/GetStarTest/testGetStarJson/



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

[jira] [Commented] (SLING-5435) Decouple processes that depend on cluster leader elections from the cluster leader elections.

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-5435:
-

[~egli] ok yes, maybe marking the listener with a property is better than 
introducing a new event type.
For the API, for now we could simply state that the API only handles one case 
(sync'ed). Adding a new method looks too confusing to me , given the little 
benefit. I don't really expect client code to be based on the API - it's more 
an informative API

> Decouple processes that depend on cluster leader elections from the cluster 
> leader elections.
> -
>
> Key: SLING-5435
> URL: https://issues.apache.org/jira/browse/SLING-5435
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Reporter: Ian Boston
>
> Currently there are many processes in Sling that must complete before a Sling 
> Discovery cluster leader election is declared complete. These processes 
> include things like transferring all Jobs from the old leader to the new 
> leader and waiting for the data to appear visible on the new leader. This 
> introduces an additional overhead to the leader election process which 
> introduces a higher than desirable timeout for elections and heartbeat. This 
> higher than desirable timeout precludes the use of more efficient election 
> and distributed consensus algorithms as implemented in Etcd, Zookeeper or 
> implementations of RAFT.
> If the election could be declared complete leaving individual components to 
> manage their own post election operations (ie decoupling those processes from 
> the election), then faster election or alternative Discovery implementations 
> such as the one implemented on etcd could be used.



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

[jira] [Updated] (SLING-5470) Resource providers might not be closed

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-5470:

Fix Version/s: (was: Resource Resolver 1.3.0)
   Resource Resolver 1.4.0

> Resource providers might not be closed
> --
>
> Key: SLING-5470
> URL: https://issues.apache.org/jira/browse/SLING-5470
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Resource Resolver 1.4.0
>
>
> The CommonResourceResolverFactoryImpl contains some code to make sure that 
> all resource resolvers (and therefore the providers) are closed - as soon as 
> there is no reference to them anymore
> With the refactoring to the new provider API, this functionality has been 
> removed - while the resource resolver context is still closed, the providers 
> are not closed (logged out)



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

[jira] [Commented] (SLING-5463) GetStarTest fails with "Invalid name or path"

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-5463:


I agree that Robert's suggestion looks reasonable.

> GetStarTest fails with "Invalid name or path"
> -
>
> Key: SLING-5463
> URL: https://issues.apache.org/jira/browse/SLING-5463
> Project: Sling
>  Issue Type: Bug
>  Components: JCR, Testing
>Reporter: Bertrand Delacretaz
>Assignee: Robert Munteanu
>  Labels: sling-IT
> Fix For: JCR Resource 2.6.0
>
>
> The GetStarTest from launchpad/integration-tests recently started failing, 
> for example at [1]:
> {code}
> javax.jcr.RepositoryException: Invalid name or path: 
> /GetStarTest1453972215267/* 
>  at 
> org.apache.jackrabbit.oak.jcr.session.SessionContext.getOakPathOrThrow(SessionContext.java:347)
> ...
>  at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.getItemOrNull(SessionImpl.java:225)
>  at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrItemResourceFactory.getItemOrNull(JcrItemResourceFactory.java:182)
>  at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrItemResourceFactory.createResource(JcrItemResourceFactory.java:96)
>  at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.listChildren(JcrResourceProvider.java:293)
>  at 
> org.apache.sling.resourceresolver.impl.providers.stateful.AuthenticatedResourceProvider.listChildren(AuthenticatedResourceProvider.java:175)
>  at 
> org.apache.sling.resourceresolver.impl.providers.stateful.CombinedResourceProvider.listChildren(CombinedResourceProvider.java:205)
>  at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.listChildren(ResourceResolverImpl.java:719)
>  at 
> org.apache.sling.api.resource.ResourceUtil.listChildren(ResourceUtil.java:360)
> ...
>  at 
> org.apache.sling.servlets.get.impl.helpers.JsonRendererServlet.doGet(JsonRendererServlet.java:100)
> {code}
> [1] 
> https://builds.apache.org/view/S-Z/view/Sling/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.launchpad.testing/3252/testReport/junit/org.apache.sling.launchpad.webapp.integrationtest/GetStarTest/testGetStarJson/



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

Re: SLING-5421 - Allow JCR installer to recover from being paused indefinitely

[Carsten Ziegeler]

Julian Sedding wrote
> Hi Carsten
> 
> There are two things to consider:
> 
> (1) moving the implementation of the repository based signalling into
> the installer (essentially encapsulation)

when you say "installer", do you mean "jcr installer" or "osgi
installer"? From below I assume jcr installer.


> (2) implementation of a robust protocol for signalling a block to
> installers on other cluster nodes
> 
> So far I have talked about (1) but didn't go into the details of (2).
> What I have in mind for (2) is a content structure that records three
> pieces of information information:
> 
> - Sling ID in order to identify on which cluster node the block was triggered
> - Service PID (i.e. the fully qualified class name of the
> implementation) in order to know which service triggered the block
> - Creation timestamp for information/debugging
> 
> The content structure would look like the following:
> 
> /system/sling/installer/jcr/pauseInstallation
> /
> /
> /
> jcr:created = 
> 
> It is important that, as a general rule, any node without children is
> eagerly deleted. This means that the installer is blocked if
> "pauseInstallation" has at least one child node and unblocked if it
> has none (or does not exist itself).
> 
> The structure would allow a single service to hold multiple blocks
> (each  node representing one).
> 
> Normally we would assume that a service blocks the installer and later
> unblocks it again, ideally using a try/finally block. However, it gets
> interesting when edge cases are considered:
> - the repository service may get stopped (or restarted), in which case
> the unblock can fail
> - a cluster node can be killed or disconnected before the unblock can be done
> - I have seen log files where the "blocking" service was restarted
> while it blocked the installer, because the installer was
> asynchronously processing a batch from a previous block. However, it
> is unclear why the unblock did not happen in this case: there were no
> exceptions in the log and I don't believe they were swallowed, because
>  when I provoked a similar scenario exceptions were written to the
> log.
> 
> To recover from such failure scenarios, the installer needs to be unblocked:
> - if a blocking service is stopped. A stopped service may still exist
> in the JVM and finish execution, therefore this could be solved using
> weak references to a block-token and a reference queue. Or
> alternatively by using a timeout in such cases.
> - if a cluster node disappears from a topology, its  node
> should be removed after a timeout
> 
> There is a danger, however, that unblocking the installer due to
> recovery causes a partial deployment to be installed. This may put the
> system into an unusable state (e.g. bundles may not be resolvable,
> because their dependencies were not updated(installed). I don't know
> how we could address this.
> 
> Maybe an entirely different approach would be to provide a list of
> deployables (e.g. repository paths?) to the installer, which then only
> installs the deployables if all are available (ignoring deployables
> with extensions it does not handle). This list would need to be
> communicated in a cluster as well, however.
> 

Thanks Julian, now I understand your idea. This might work, however
sounds a little bit complex to me.
Now, obviously, the easier solution is that the content package which
installs the bundles in the first place, is installed through the OSGi
installer - as the OSGi installer is single threaded, bundles installed
through content packages would be installed after all content is
installed. And no pausing would be needed as well.
So, I think pausing and trying to recover etc. is a house made problem
which could be avoided if the root cause would be solved.

Carsten

> Regards
> Julian
> 
> 
> On Sun, Jan 31, 2016 at 10:34 AM, Carsten Ziegeler  
> wrote:
>> Julian Sedding wrote
>>> Hi Carsten
>>>
 Offline discussions don't make it transparent why you came to this
 conclusion.
 Please enclose the relevant information either here or in the issue.
>>>
>>> Sure, I thought that I included some information both in the email and
>>> in the issue. But it is probably worthwhile to expand on it a bit
>>> more.
>>>
>>> The current implementation is based on a convention rather than a
>>> contract: place a node under a specific parent node and the JCR
>>> installer will pause its activities.
>>>
>>> It turns out that this convention in this simple form has limitations
>>> when things go wrong:
>>>
>>> - If a "deployer" implementation fails to delete the pause-marker node
>>> (no matter what the reasons are), whose responsibility is it to delete
>>> this node to recover the system?
>>> - If a "deployer" on cluster node A creates a pause-marker node and
>>> then cluster node A is shut down/crashes/disconnects, whose
>>> responsibility is it to delete this node to recover the system?
>>>
>>> Both 

Re: SLING-5421 - Allow JCR installer to recover from being paused indefinitely

[Julian Sedding]

Hi Carsten

Thanks for your comments. I agree that it would be nice if we could
avoid pausing the installer altogether.

However, I see some challenges:
- How do we make sure all nodes in a cluster install the bundles into
their OSGi environments in a single batch?
- Currently content packages contain bundles that are installed into
the repository. How could we prevent duplicate installation (by the
JCR installer triggered via observation and directly by the OSGi
installer)?

Do you think it is realistic to solve these issues in the short term?

Even if we can solve them, we will still need reliable
communication/coordination between cluster nodes. This part, as
Bertrand suggested in the issue, could be made generic. AFAIK
ZooKeeper, etcd et al. provide such mechanisms. Maybe we need to
provide an implementation agnostic API for this in the discovery
module.

Regards
Julian



On Mon, Feb 1, 2016 at 12:49 PM, Carsten Ziegeler  wrote:
> Julian Sedding wrote
>> Hi Carsten
>>
>> There are two things to consider:
>>
>> (1) moving the implementation of the repository based signalling into
>> the installer (essentially encapsulation)
>
> when you say "installer", do you mean "jcr installer" or "osgi
> installer"? From below I assume jcr installer.
>
>
>> (2) implementation of a robust protocol for signalling a block to
>> installers on other cluster nodes
>>
>> So far I have talked about (1) but didn't go into the details of (2).
>> What I have in mind for (2) is a content structure that records three
>> pieces of information information:
>>
>> - Sling ID in order to identify on which cluster node the block was triggered
>> - Service PID (i.e. the fully qualified class name of the
>> implementation) in order to know which service triggered the block
>> - Creation timestamp for information/debugging
>>
>> The content structure would look like the following:
>>
>> /system/sling/installer/jcr/pauseInstallation
>> /
>> /
>> /
>> jcr:created = 
>>
>> It is important that, as a general rule, any node without children is
>> eagerly deleted. This means that the installer is blocked if
>> "pauseInstallation" has at least one child node and unblocked if it
>> has none (or does not exist itself).
>>
>> The structure would allow a single service to hold multiple blocks
>> (each  node representing one).
>>
>> Normally we would assume that a service blocks the installer and later
>> unblocks it again, ideally using a try/finally block. However, it gets
>> interesting when edge cases are considered:
>> - the repository service may get stopped (or restarted), in which case
>> the unblock can fail
>> - a cluster node can be killed or disconnected before the unblock can be done
>> - I have seen log files where the "blocking" service was restarted
>> while it blocked the installer, because the installer was
>> asynchronously processing a batch from a previous block. However, it
>> is unclear why the unblock did not happen in this case: there were no
>> exceptions in the log and I don't believe they were swallowed, because
>>  when I provoked a similar scenario exceptions were written to the
>> log.
>>
>> To recover from such failure scenarios, the installer needs to be unblocked:
>> - if a blocking service is stopped. A stopped service may still exist
>> in the JVM and finish execution, therefore this could be solved using
>> weak references to a block-token and a reference queue. Or
>> alternatively by using a timeout in such cases.
>> - if a cluster node disappears from a topology, its  node
>> should be removed after a timeout
>>
>> There is a danger, however, that unblocking the installer due to
>> recovery causes a partial deployment to be installed. This may put the
>> system into an unusable state (e.g. bundles may not be resolvable,
>> because their dependencies were not updated(installed). I don't know
>> how we could address this.
>>
>> Maybe an entirely different approach would be to provide a list of
>> deployables (e.g. repository paths?) to the installer, which then only
>> installs the deployables if all are available (ignoring deployables
>> with extensions it does not handle). This list would need to be
>> communicated in a cluster as well, however.
>>
>
> Thanks Julian, now I understand your idea. This might work, however
> sounds a little bit complex to me.
> Now, obviously, the easier solution is that the content package which
> installs the bundles in the first place, is installed through the OSGi
> installer - as the OSGi installer is single threaded, bundles installed
> through content packages would be installed after all content is
> installed. And no pausing would be needed as well.
> So, I think pausing and trying to recover etc. is a house made problem
> which could be avoided if the root cause would be solved.
>
> Carsten
>
>> Regards
>> Julian
>>
>>
>> On Sun, Jan 31, 2016 at 10:34 AM, Carsten Ziegeler  
>> wrote:
>>> 

[jira] [Created] (SLING-5474) [HApi] Move sightly use objects to a different package

[Andrei Dulvac (JIRA)]

Andrei Dulvac created SLING-5474:


 Summary: [HApi] Move sightly use objects to a different package
 Key: SLING-5474
 URL: https://issues.apache.org/jira/browse/SLING-5474
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Andrei Dulvac


Move HApiUse and TypeView use objects to the {{sightly}} sub-package



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

[jira] [Updated] (SLING-5474) [HApi] Move sightly use objects to a different package

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-5474:

Fix Version/s: HApi 1.0.0

> [HApi] Move sightly use objects to a different package
> --
>
> Key: SLING-5474
> URL: https://issues.apache.org/jira/browse/SLING-5474
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Andrei Dulvac
>  Labels: hapi
> Fix For: HApi 1.0.0
>
> Attachments: SLING-5474.diff
>
>
> Move HApiUse and TypeView use objects to the {{sightly}} sub-package



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

[jira] [Assigned] (SLING-5474) [HApi] Move sightly use objects to a different package

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler reassigned SLING-5474:
---

Assignee: Carsten Ziegeler

> [HApi] Move sightly use objects to a different package
> --
>
> Key: SLING-5474
> URL: https://issues.apache.org/jira/browse/SLING-5474
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Andrei Dulvac
>Assignee: Carsten Ziegeler
>  Labels: hapi
> Fix For: HApi 1.0.0
>
> Attachments: SLING-5474.diff
>
>
> Move HApiUse and TypeView use objects to the {{sightly}} sub-package



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

[jira] [Updated] (SLING-5061) [HApi] HApiType.getUrl() should be an absolute URL

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-5061:

Fix Version/s: HApi 1.0.0

> [HApi] HApiType.getUrl() should be an absolute URL
> --
>
> Key: SLING-5061
> URL: https://issues.apache.org/jira/browse/SLING-5061
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Andrei Dulvac
>Assignee: Bertrand Delacretaz
>Priority: Minor
>  Labels: PatchAvailable
> Fix For: HApi 1.0.0
>
> Attachments: SLING-5061.git.patch
>
>
> The Hypermedia API tools HApiType.getUrl() should return an absolute 
> resolvable URL. In its current implementation, it's used to add a URL to the 
> _itemtype_ attribute in microdata, and the spec says the URL should be 
> absolute.
> The fix allows an OSGi config with an _external url_ that gets prepended to 
> the repository path + extension.
> Patch attached



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

[jira] [Updated] (SLING-5390) [HApi] Allow HApi microdata client to fitler links and forms based on a relation set as class

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-5390:

Fix Version/s: HApi 1.0.0

> [HApi] Allow HApi microdata client to fitler links and forms based on a 
> relation set as class
> -
>
> Key: SLING-5390
> URL: https://issues.apache.org/jira/browse/SLING-5390
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Andrei Dulvac
>Assignee: Bertrand Delacretaz
>  Labels: PatchAvailable
> Fix For: HApi 1.0.0
>
> Attachments: SLING-5390.git.patch
>
>
> The HApi client allows identifying anchors, links and forms based on the rel 
> and data-rel attributes, respectively (as rel is not allowed on form). For 
> added flexibility, it would be needed that the relation string passed to 
> those methods is also checked against the CSS class of the elements.



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

[jira] [Updated] (SLING-5371) JcrInstaller should not listen on / for moves

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated SLING-5371:
---
Fix Version/s: JCR Installer 3.1.18

> JcrInstaller should not listen on / for moves
> -
>
> Key: SLING-5371
> URL: https://issues.apache.org/jira/browse/SLING-5371
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Affects Versions: JCR Installer 3.1.16
>Reporter: Marc Pfaff
>Assignee: Bertrand Delacretaz
> Fix For: JCR Installer 3.1.18
>
> Attachments: SLING_5371.patch, SLING_5371_fixing_testclass.patch, 
> SLING_5371_jackrabbit.patch, SLING_5371_jcr_only.patch
>
>
> The JcrInstaller is currently registering a JCR listener for move events on 
> the root node with setting the 'deep' property to true. If it comes to 
> processing the underlaying Oak observation queue, this combination is very 
> inefficient, as it does not allow Oak to filter changes by path. 
> AFAIU this move listener is covering the use case where an installer artifact 
> is moved from/to an installer root folder. I therefore wanted to propose to 
> register the move listener on the configured root folders only.  



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

[jira] [Updated] (SLING-5371) JcrInstaller should not listen on / for moves

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated SLING-5371:
---
Affects Version/s: JCR Installer 3.1.16

> JcrInstaller should not listen on / for moves
> -
>
> Key: SLING-5371
> URL: https://issues.apache.org/jira/browse/SLING-5371
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Affects Versions: JCR Installer 3.1.16
>Reporter: Marc Pfaff
>Assignee: Bertrand Delacretaz
> Fix For: JCR Installer 3.1.18
>
> Attachments: SLING_5371.patch, SLING_5371_fixing_testclass.patch, 
> SLING_5371_jackrabbit.patch, SLING_5371_jcr_only.patch
>
>
> The JcrInstaller is currently registering a JCR listener for move events on 
> the root node with setting the 'deep' property to true. If it comes to 
> processing the underlaying Oak observation queue, this combination is very 
> inefficient, as it does not allow Oak to filter changes by path. 
> AFAIU this move listener is covering the use case where an installer artifact 
> is moved from/to an installer root folder. I therefore wanted to propose to 
> register the move listener on the configured root folders only.  



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

[jira] [Resolved] (SLING-5371) JcrInstaller should not listen on / for moves

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz resolved SLING-5371.

Resolution: Fixed

Good catch, the test obviously works for me as well now. I have applied your 
patch in revision 1728047, marking this ticket fixed, thanks!

> JcrInstaller should not listen on / for moves
> -
>
> Key: SLING-5371
> URL: https://issues.apache.org/jira/browse/SLING-5371
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Reporter: Marc Pfaff
>Assignee: Bertrand Delacretaz
> Attachments: SLING_5371.patch, SLING_5371_fixing_testclass.patch, 
> SLING_5371_jackrabbit.patch, SLING_5371_jcr_only.patch
>
>
> The JcrInstaller is currently registering a JCR listener for move events on 
> the root node with setting the 'deep' property to true. If it comes to 
> processing the underlaying Oak observation queue, this combination is very 
> inefficient, as it does not allow Oak to filter changes by path. 
> AFAIU this move listener is covering the use case where an installer artifact 
> is moved from/to an installer root folder. I therefore wanted to propose to 
> register the move listener on the configured root folders only.  



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

[jira] [Commented] (SLING-5443) Review the naming conventions used by JMXReporter to register the Metric MBeans

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-5443:
-

I think having a service factory is good, having a global mapping is not very 
user friendly . It makes it hard for each bundle to provide it's own mapping - 
we could work with factory configurations, but that still seems be a lot of 
overhead
Instead, I suggest we simply use a bundle header for the mapping. If none is 
available, the bundle symbolic name is used, otherwise the value from that 
header is used instead.

> Review the naming conventions used by JMXReporter to register the Metric 
> MBeans
> ---
>
> Key: SLING-5443
> URL: https://issues.apache.org/jira/browse/SLING-5443
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Commons Metrics 1.0.2
>
>
> With current setup the JMXReporter would register all metrics under 
> {{org.apache.sling}} domain. [~pfa...@adobe.com] suggested that this can 
> cause confusion as metrics registered by non Sling bundle would also show up 
> in Sling JMX domain. 
> We should customize the JMX ObjectName logic to account for bundle which has 
> registered the metrics. One approach that can be used is 
> # Expose the MetricService as a ServiceFactory
> # Have an OSGi config which provides a mapping between Bundle-SymbolicName 
> and JMX Domain name to use. It would be a regex expression. The metric though 
> MUST be unique across all metrics (irrespective of which bundle was used)
> {noformat}
> com.foo = com.foo.*
> org.apache.sling=org.apache.sling.*
> {noformat}
> Discussion thread on mailing list http://markmail.org/thread/sj6yvmyhgze6jn22



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

[jira] [Updated] (SLING-5449) Content repository initialization language

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated SLING-5449:
---
Description: 
Discussions on our dev list and with my colleagues around SLING-5355 (the ACL 
definition language) show that we need to initialize a number of things when 
starting on a new or existing content repository:

* Create the "base tree", paths like /libs, /apps, /var that many modules use 
and sometimes compete to create.
* Create service users
* Set ACLs on the base tree for those service users
* And maybe setup some JCR-specific things like node types and custom 
privileges, that other content repositories would ignore.

I'll create a more general module than what I created for SLING-5355 (which 
hasn't been released) to cover those things, and put it under 
{{commons/repoinit}} as it shouldn't have any dependencies on Sling. We might 
donate it to Jackrabbit once it matures but for now my goal is to implement the 
whole cycle inside Sling as it's the primary customer of that.

The JCR-specific APIs should only use a JCR Session as a handle to the content 
repository, to keep this independent of Sling and allow it to be used in other 
contexts like tests.

_Edit: changed the path from {{commons/jcrinit}} to {{commons/repoinit}}, even 
if some parts are specific to JCR the repoinit language will be mostly generic_

  was:
Discussions on our dev list and with my colleagues around SLING-5355 (the ACL 
definition language) show that we need to initialize a number of things when 
starting on a new or existing content repository:

* Create the "base tree", paths like /libs, /apps, /var that many modules use 
and sometimes compete to create.
* Create service users
* Set ACLs on the base tree for those service users
* And maybe setup some JCR-specific things like node types and custom 
privileges, that other content repositories would ignore.

I'll create a more general module than what I created for SLING-5355 (which 
hasn't been released) to cover those things, and put it under 
{{commons/jcrinit}} as it shouldn't have any dependencies on Sling. We might 
donate it to Jackrabbit once it matures but for now my goal is to implement the 
whole cycle inside Sling as it's the primary customer of that.

The JCR-specific APIs should only use a JCR Session as a handle to the content 
repository, to keep this independent of Sling and allow it to be used in other 
contexts like tests.


> Content repository initialization language
> --
>
> Key: SLING-5449
> URL: https://issues.apache.org/jira/browse/SLING-5449
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Attachments: SLING-5449-launchpad-testing.patch
>
>
> Discussions on our dev list and with my colleagues around SLING-5355 (the ACL 
> definition language) show that we need to initialize a number of things when 
> starting on a new or existing content repository:
> * Create the "base tree", paths like /libs, /apps, /var that many modules use 
> and sometimes compete to create.
> * Create service users
> * Set ACLs on the base tree for those service users
> * And maybe setup some JCR-specific things like node types and custom 
> privileges, that other content repositories would ignore.
> I'll create a more general module than what I created for SLING-5355 (which 
> hasn't been released) to cover those things, and put it under 
> {{commons/repoinit}} as it shouldn't have any dependencies on Sling. We might 
> donate it to Jackrabbit once it matures but for now my goal is to implement 
> the whole cycle inside Sling as it's the primary customer of that.
> The JCR-specific APIs should only use a JCR Session as a handle to the 
> content repository, to keep this independent of Sling and allow it to be used 
> in other contexts like tests.
> _Edit: changed the path from {{commons/jcrinit}} to {{commons/repoinit}}, 
> even if some parts are specific to JCR the repoinit language will be mostly 
> generic_



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

[jira] [Resolved] (SLING-5473) Improve parallelism of package acquire/release

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5473.
--
Resolution: Fixed

Committed revision 1727953.


> Improve parallelism of package acquire/release
> --
>
> Key: SLING-5473
> URL: https://issues.apache.org/jira/browse/SLING-5473
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.14
>
>
> We should not use locks when acquiring/releasing packages



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

[jira] [Commented] (SLING-5449) Content repository initialization language

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-5449:


I have added a RepositoryInitializer in http://svn.apache.org/r1727946 that 
executes the {{launchpad/test-services/src/main/resources/repoinit.txt}} 
statements. 

We can use this to create any system users that the tests require, as well as 
set their ACLs, but it means that I'll need to add the base tree creation 
statements to the repoinit language soon, so that the paths on which ACLs are 
set are created before setting those ACLs.

> Content repository initialization language
> --
>
> Key: SLING-5449
> URL: https://issues.apache.org/jira/browse/SLING-5449
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Attachments: SLING-5449-launchpad-testing.patch
>
>
> Discussions on our dev list and with my colleagues around SLING-5355 (the ACL 
> definition language) show that we need to initialize a number of things when 
> starting on a new or existing content repository:
> * Create the "base tree", paths like /libs, /apps, /var that many modules use 
> and sometimes compete to create.
> * Create service users
> * Set ACLs on the base tree for those service users
> * And maybe setup some JCR-specific things like node types and custom 
> privileges, that other content repositories would ignore.
> I'll create a more general module than what I created for SLING-5355 (which 
> hasn't been released) to cover those things, and put it under 
> {{commons/jcrinit}} as it shouldn't have any dependencies on Sling. We might 
> donate it to Jackrabbit once it matures but for now my goal is to implement 
> the whole cycle inside Sling as it's the primary customer of that.
> The JCR-specific APIs should only use a JCR Session as a handle to the 
> content repository, to keep this independent of Sling and allow it to be used 
> in other contexts like tests.



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

[jira] [Created] (SLING-5473) Improve parallelism of package acquire/release

[Marius Petria (JIRA)]

Marius Petria created SLING-5473:


 Summary: Improve parallelism of package acquire/release
 Key: SLING-5473
 URL: https://issues.apache.org/jira/browse/SLING-5473
 Project: Sling
  Issue Type: Bug
  Components: Distribution
Reporter: Marius Petria
Assignee: Marius Petria
 Fix For: Content Distribution Core 0.1.14


We should not use locks when acquiring/releasing packages



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

[jira] [Commented] (SLING-5463) GetStarTest fails with "Invalid name or path"

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-5463:


FWIW this issue exposed a minor bug in an integration test, fixed in 
http://svn.apache.org/r1727949 - what happened was that a request with a 
doubled slash like {{http://localhost:8080//tmp}} and an Accept header set to 
JSON would return an HTML formatted error instead of JSON, as this issue causes 
it to fail deeper in the stack. No big deal but a possible side effect of this 
worth mentioning.

> GetStarTest fails with "Invalid name or path"
> -
>
> Key: SLING-5463
> URL: https://issues.apache.org/jira/browse/SLING-5463
> Project: Sling
>  Issue Type: Bug
>  Components: JCR, Testing
>Reporter: Bertrand Delacretaz
>Assignee: Robert Munteanu
>  Labels: sling-IT
> Fix For: JCR Resource 2.6.0
>
>
> The GetStarTest from launchpad/integration-tests recently started failing, 
> for example at [1]:
> {code}
> javax.jcr.RepositoryException: Invalid name or path: 
> /GetStarTest1453972215267/* 
>  at 
> org.apache.jackrabbit.oak.jcr.session.SessionContext.getOakPathOrThrow(SessionContext.java:347)
> ...
>  at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.getItemOrNull(SessionImpl.java:225)
>  at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrItemResourceFactory.getItemOrNull(JcrItemResourceFactory.java:182)
>  at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrItemResourceFactory.createResource(JcrItemResourceFactory.java:96)
>  at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.listChildren(JcrResourceProvider.java:293)
>  at 
> org.apache.sling.resourceresolver.impl.providers.stateful.AuthenticatedResourceProvider.listChildren(AuthenticatedResourceProvider.java:175)
>  at 
> org.apache.sling.resourceresolver.impl.providers.stateful.CombinedResourceProvider.listChildren(CombinedResourceProvider.java:205)
>  at 
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.listChildren(ResourceResolverImpl.java:719)
>  at 
> org.apache.sling.api.resource.ResourceUtil.listChildren(ResourceUtil.java:360)
> ...
>  at 
> org.apache.sling.servlets.get.impl.helpers.JsonRendererServlet.doGet(JsonRendererServlet.java:100)
> {code}
> [1] 
> https://builds.apache.org/view/S-Z/view/Sling/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.launchpad.testing/3252/testReport/junit/org.apache.sling.launchpad.webapp.integrationtest/GetStarTest/testGetStarJson/



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