[
https://issues.apache.org/jira/browse/SLING-7811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16571431#comment-16571431
]
Robert Munteanu commented on SLING-7811:
----------------------------------------
I'm a bit stuck here, [~cziegeler], [~jsedding], maybe you have a better idea.
With the root cause identified in my comment above, I reviewed the
{{AbstractSlingRepositoryManager}} and wanted to simplify things a bit (maybe a
bad idea :-) ).
The first suspect was the async initialisation of the repository, from
https://github.com/apache/sling-org-apache-sling-jcr-base/blob/org.apache.sling.jcr.base-3.0.4/src/main/java/org/apache/sling/jcr/base/AbstractSlingRepositoryManager.java#L450-L460
:
{code:java}
// start repository asynchronously to allow LoginAdminWhitelist to
become available
// NOTE: making this conditional allows tests to register a mock
whitelist before
// activating the RepositoryManager, so they don't need to deal with
async startup
new Thread("Apache Sling Repository Startup Thread") {
@Override
public void run() {
try {
waitForWhitelist.await();
initializeAndRegisterRepositoryService();
} catch (InterruptedException e) {
throw new RuntimeException("Interrupted while waiting for
LoginAdminWhitelist", e);
}
}
}.start();
{code}
The {{waitForWhiteList.await()}} call waits for
{{waitForWhiteList.countDown()}} to be invoked in a {{ServiceTracker}}, see
https://github.com/apache/sling-org-apache-sling-jcr-base/blob/org.apache.sling.jcr.base-3.0.4/src/main/java/org/apache/sling/jcr/base/AbstractSlingRepositoryManager.java#L431-L445
{code:java}
// If allowLoginAdministrativeForBundle is overridden we assume we
don't need
// a LoginAdminWhitelist service - that's the case if the derived class
// implements its own strategy and the LoginAdminWhitelist interface is
// not exported by this bundle anyway, so cannot be implemented
differently.
boolean enableWhitelist =
!isAllowLoginAdministrativeForBundleOverridden();
final CountDownLatch waitForWhitelist = new
CountDownLatch(enableWhitelist ? 1 : 0);
if (enableWhitelist) {
whitelistTracker = new ServiceTracker<LoginAdminWhitelist,
LoginAdminWhitelist>(bundleContext, LoginAdminWhitelist.class, null) {
@Override
public LoginAdminWhitelist addingService(final
ServiceReference<LoginAdminWhitelist> reference) {
try {
return super.addingService(reference);
} finally {
waitForWhitelist.countDown();
}
}
};
whitelistTracker.open();
}
{code}
IMO there is no need to start the repository in an async manner as the
{{ServiceTracker}} will be invoked on a different thread. Making the removing
the thread and starting the repository in the same thread had the nasty side
effect to no bundle being considered as whitelisted for login administrative.
I debugged this and apparently the {{LoginAdminWhitelist}} component is
registered well ahead and receives no {{LoginAdminWhitelist.fragment}} configs
until later on.
I tried to configure the {{LoginAdminWhitelist}} component to wait for a number
of references to come up before being registered:
{code}
org.apache.sling.jcr.base.internal.LoginAdminWhitelist
WhitelistFragment.cardinality.minimum="2"
{code}
But unfortunately that configuration is also applied too late and the
{{LoginAdminWhitelist}} service is registered too early.
Any ideas on how to approach this are very much welcome.
> NPE when repository is starting up
> ----------------------------------
>
> Key: SLING-7811
> URL: https://issues.apache.org/jira/browse/SLING-7811
> Project: Sling
> Issue Type: Bug
> Components: JCR
> Affects Versions: JCR Oak Server 1.1.4, JCR Base 3.0.4
> Reporter: Carsten Ziegeler
> Assignee: Robert Munteanu
> Priority: Major
> Fix For: JCR Base 3.0.6, JCR Oak Server 1.2.2
>
>
> With the latest Sling Starter, the following NPE occurs in the logs. It seems
> to be harmless, nevertheless we should fix it:
> For now I assigned it to both, JCR Base and Oak Server, as it's unclear which
> one it is. Interestingly we've released Oak Server 1.2.0 but are not using it
> in the starter.
> {noformat}
> 06.08.2018 15:45:18.396 *ERROR* [Apache Sling Repository Startup Thread]
> org.apache.sling.jcr.oak.server.internal.OakSlingRepositoryManager start:
> Uncaught Throwable trying to access Repository, calling stopRepository()
> java.lang.NullPointerException: null
> at
> com.google.common.base.Preconditions.checkNotNull(Preconditions.java:192)
> [com.google.guava:15.0.0]
> at org.apache.jackrabbit.oak.jcr.Jcr.with(Jcr.java:296)
> [org.apache.jackrabbit.oak-jcr:1.6.8]
> at
> org.apache.sling.jcr.oak.server.internal.OakSlingRepositoryManager.acquireRepository(OakSlingRepositoryManager.java:161)
> [org.apache.sling.jcr.oak.server:1.1.4]
> at
> org.apache.sling.jcr.base.AbstractSlingRepositoryManager.initializeAndRegisterRepositoryService(AbstractSlingRepositoryManager.java:471)
> [org.apache.sling.jcr.base:3.0.4]
> at
> org.apache.sling.jcr.base.AbstractSlingRepositoryManager.access$300(AbstractSlingRepositoryManager.java:85)
> [org.apache.sling.jcr.base:3.0.4]
> at
> org.apache.sling.jcr.base.AbstractSlingRepositoryManager$4.run(AbstractSlingRepositoryManager.java:455)
> [org.apache.sling.jcr.base:3.0.4]
> {noformat}
> The stack trace points to a null workspace name ( see
> https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.8/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/Jcr.java#L296
> ).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
