[jira] [Reopened] (SLING-3529) Move startup handling to a separate bundle
[ https://issues.apache.org/jira/browse/SLING-3529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reopened SLING-3529: - Move startup handling to a separate bundle -- Key: SLING-3529 URL: https://issues.apache.org/jira/browse/SLING-3529 Project: Sling Issue Type: New Feature Components: Launchpad Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler The startup handler is currently embedded in the Sling launchpad base - which makes it impossible to use when Sling is installed in another container like e.g. Apache Karaf. We should move this to a separate bundle to make it more reusable -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3652) Sling Job Consumer Manager : Distribute config should be disabled by default
[ https://issues.apache.org/jira/browse/SLING-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14092537#comment-14092537 ] Ashutosh Shroti commented on SLING-3652: [~cziegeler] When instance started up in a cluster, changes in configuration of one instance are getting distributed to others by default (though the default value of distribute config is false if look at felix console). After re-setting this config (set true the false) will actually help us to stop distribution of the configuration changes across instances, which is an un-necessary step in my opinion. [~amitgupt] has also reproduced this issue along with me, what is your input on this? Sling Job Consumer Manager : Distribute config should be disabled by default Key: SLING-3652 URL: https://issues.apache.org/jira/browse/SLING-3652 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Event 3.3.10 Reporter: Ashutosh Shroti Assignee: Amit Gupta Sling Job Consumer Manager service have an following flag: Distribute config - disabled This should be disabled by default. Use Case: While configuring author instances in the cluster, config changes like disable the listener on topic com/adobe/granite/workflow/offloading should be local to an instance. Hence above mentioned flag should be disabled by default to prevent config changes to local instance. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3265) Implement suggestions from SLING-3223 in Sling replication
[ https://issues.apache.org/jira/browse/SLING-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3265: --- Component/s: (was: Extensions) Replication Labels: (was: replication) Implement suggestions from SLING-3223 in Sling replication -- Key: SLING-3265 URL: https://issues.apache.org/jira/browse/SLING-3265 Project: Sling Issue Type: Improvement Components: Replication Reporter: Tommaso Teofili Attachments: SLING-3265.2.patch, SLING-3265.patch Umbrella issue to track implementation of improvements for Sling Replication as suggested in SLING-3223 comments. Main ones refer to: - more tests - fix javadoc / typos - avoid AdapterFactory for installing packages - fix action names - refactor AuthenticationHandlers -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3394) Fix agent isPassive (reverse replication) checks
[ https://issues.apache.org/jira/browse/SLING-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3394: --- Component/s: (was: Extensions) Replication Labels: (was: replication) Fix agent isPassive (reverse replication) checks Key: SLING-3394 URL: https://issues.apache.org/jira/browse/SLING-3394 Project: Sling Issue Type: Bug Components: Replication Reporter: Tommaso Teofili Assignee: Tommaso Teofili the SimpleReplicationAgent#isPassive method is not working as the TransportHandler initialization in ReplicationAgentServiceFactory has changed due to the move of TransportHandlers as own configurations and services hence that reference can never be null. Also its usage in SimpleReplicationAgent#removeHead is inverted and breaks the reverse replication scenario. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3310) Use a released parent POM in Sling Replication
[ https://issues.apache.org/jira/browse/SLING-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3310: --- Component/s: (was: Extensions) Replication Labels: (was: replication) Use a released parent POM in Sling Replication --- Key: SLING-3310 URL: https://issues.apache.org/jira/browse/SLING-3310 Project: Sling Issue Type: Task Components: Replication Reporter: Tommaso Teofili Priority: Trivial Attachments: SLING-3310.patch As other contrib/extensions modules it'd be good for Sling Replication to use a released parent POM (at 19-SNAPSHOT instead at the moment) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3404) JobHandlingReplicationQueue reports failed Job.toString
[ https://issues.apache.org/jira/browse/SLING-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3404: --- Component/s: (was: Extensions) Replication Labels: (was: replication) JobHandlingReplicationQueue reports failed Job.toString --- Key: SLING-3404 URL: https://issues.apache.org/jira/browse/SLING-3404 Project: Sling Issue Type: Improvement Components: Replication Reporter: Tommaso Teofili Assignee: Tommaso Teofili JobHandlingReplicationQueue currently logs an INFO message when a Job is created internally, however this triggers a strange ConcurrentModificationException : SLF4J: Failed toString() invocation on an object of type [org.apache.sling.event.impl.jobs.JobImpl] java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793) at java.util.HashMap$EntryIterator.next(HashMap.java:834) at java.util.HashMap$EntryIterator.next(HashMap.java:832) at java.util.AbstractMap.toString(AbstractMap.java:485) at org.apache.sling.api.wrappers.ValueMapDecorator.toString(ValueMapDecorator.java:210) at java.lang.String.valueOf(String.java:2826) at java.lang.StringBuilder.append(StringBuilder.java:115) at org.apache.sling.event.impl.jobs.JobImpl.toString(JobImpl.java:383) at org.slf4j.helpers.MessageFormatter.safeObjectAppend(MessageFormatter.java:304) at org.slf4j.helpers.MessageFormatter.deeplyAppendParameter(MessageFormatter.java:276) at org.slf4j.helpers.MessageFormatter.arrayFormat(MessageFormatter.java:230) at ch.qos.logback.classic.spi.LoggingEvent.getFormattedMessage(LoggingEvent.java:298) at ch.qos.logback.classic.spi.LoggingEvent.prepareForDeferredProcessing(LoggingEvent.java:208) at ch.qos.logback.core.OutputStreamAppender.subAppend(OutputStreamAppender.java:206) at ch.qos.logback.core.rolling.RollingFileAppender.subAppend(RollingFileAppender.java:175) at ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:103) at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:88) at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:48) at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:273) at ch.qos.logback.classic.Logger.callAppenders(Logger.java:260) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:442) at ch.qos.logback.classic.Logger.filterAndLog_1(Logger.java:414) at ch.qos.logback.classic.Logger.info(Logger.java:604) at org.apache.sling.replication.queue.impl.jobhandling.JobHandlingReplicationQueue.add(JobHandlingReplicationQueue.java:72) at org.apache.sling.replication.queue.impl.ErrorAwareQueueDistributionStrategy.offer(ErrorAwareQueueDistributionStrategy.java:115) at org.apache.sling.replication.agent.impl.SimpleReplicationAgent.schedule(SimpleReplicationAgent.java:167) at org.apache.sling.replication.agent.impl.SimpleReplicationAgent.schedule(SimpleReplicationAgent.java:149) at org.apache.sling.replication.agent.impl.SimpleReplicationAgent.send(SimpleReplicationAgent.java:104) at org.apache.sling.replication.rule.impl.ScheduleReplicateReplicationRule$ScheduledReplication.run(ScheduleReplicateReplicationRule.java:95) at org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:105) at org.quartz.core.JobRunShell.run(JobRunShell.java:207) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) at java.lang.Thread.run(Thread.java:695) The trivial workaround for the replication queue is to switch to log, for example, just the ID or something else. However it'd be interesting to understand what's causing it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3385) Expose replication agents actions and information via HTTP.
[
https://issues.apache.org/jira/browse/SLING-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili updated SLING-3385:
---
Component/s: (was: Extensions)
Replication
Labels: (was: replication)
Expose replication agents actions and information via HTTP.
-
Key: SLING-3385
URL: https://issues.apache.org/jira/browse/SLING-3385
Project: Sling
Issue Type: Bug
Components: Replication
Reporter: Marius Petria
We need a safe way to expose replication agents actions via HTTP.
Replication agents are OSGI services that can do the following actions:
- replicate a content tree (build a content package and add it to a queue)
- add a content package into a queue
- remove a content package from its queue
A replication agent also exposes information about packages in its queues.
We have to expose all this actions and information over HTTP in order to be
available to authorized users.
Actions:
- Replicate (schedules a replication action)
POST /system/replication/agents
X-replication-action: ADD/DELETE
X-replication-path: /content/mycontent
X-replication-agent: {agentName}
- Import/Export (adds or removes a package from a queue)
POST /system/replication/packages
X-replication-action: PACKAGE_OFFER/PACKAGE_POLL
X-replication-queue: {queueName}
X-replication-agent: {agentName}
-Information about agents, queues, packages
GET /system/replication/agents?agent={agentName}
GET /system/replication/queues?agent={agentName}
GET /system/replication/packages?queue={queueName}agent={agentName}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (SLING-3298) PollingTransportHandler should have a configurable no. of consecutive polls
[ https://issues.apache.org/jira/browse/SLING-3298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3298: --- Component/s: (was: Extensions) Replication Labels: (was: replication) PollingTransportHandler should have a configurable no. of consecutive polls --- Key: SLING-3298 URL: https://issues.apache.org/jira/browse/SLING-3298 Project: Sling Issue Type: Improvement Components: Replication Reporter: Tommaso Teofili Attachments: SLING-3298.patch By default the PollingTransportHandler tries to consume all the available package streams on the remote instance, this should be configurable (keeping the current default) to address scenarios where there might be too many items to fetch in a single call (even if currently they'd be different HTTP requests). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3299) Remote agent queue poll should be restricted as queueing agents
[ https://issues.apache.org/jira/browse/SLING-3299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3299: --- Component/s: (was: Extensions) Replication Labels: (was: replication) Remote agent queue poll should be restricted as queueing agents - Key: SLING-3299 URL: https://issues.apache.org/jira/browse/SLING-3299 Project: Sling Issue Type: Improvement Components: Replication Reporter: Tommaso Teofili Assignee: Bertrand Delacretaz Attachments: SLING-3299.patch ReplicationAgentPollServlet should only poll from agents used for queuing packages (having null or empty endpoint). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3330) Allow asynchronous package import
[ https://issues.apache.org/jira/browse/SLING-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3330: --- Component/s: (was: Extensions) Replication Labels: (was: replication) Allow asynchronous package import - Key: SLING-3330 URL: https://issues.apache.org/jira/browse/SLING-3330 Project: Sling Issue Type: Improvement Components: Replication Reporter: Tommaso Teofili Assignee: Tommaso Teofili Let the ReplicationPackageImporter be able to import replication package streams asynchronously, this will involve having its own queue. In the future it may be worth moving such functionalities directly into polling agents so that existing queue providers and queue distribution strategy can be used also for package imports. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3833) Cleanup ReplicationAgent interface and ReplicationAgentConfiguration
[ https://issues.apache.org/jira/browse/SLING-3833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3833: --- Component/s: (was: Extensions) Replication Labels: (was: replication) Cleanup ReplicationAgent interface and ReplicationAgentConfiguration Key: SLING-3833 URL: https://issues.apache.org/jira/browse/SLING-3833 Project: Sling Issue Type: Improvement Components: Replication Reporter: Marius Petria Assignee: Tommaso Teofili Attachments: SLING-3833.patch ReplicationAgent should have a minimal interface. More specifically a client should be able to schedule a ReplicationRequest and to visualize the ReplicationQueues. If we decide that synchronous execution is needed then that should be properly implemented as the current version is not synchronous. Also, agent configuration is particular to the SimpleReplicationAgent implementation. It is true that it is the single implementation that we have but it cannot be an API unless we decide on a fixed set of properties that all agent implementations should have. Either way configurations are currently accessible through the custom resource provider. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3281) Expose more information on the replication queues
[ https://issues.apache.org/jira/browse/SLING-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3281: --- Component/s: (was: Extensions) Replication Labels: (was: replication) Expose more information on the replication queues - Key: SLING-3281 URL: https://issues.apache.org/jira/browse/SLING-3281 Project: Sling Issue Type: Task Components: Replication Reporter: Tommaso Teofili Assignee: Bertrand Delacretaz Attachments: SLING-3281.2.patch, SLING-3281.3.patch, SLING-3281.4.patch, SLING-3281.5.patch, SLING-3281.patch It'd be useful to have more information on: 1. the items contained in a replication queue being still be able to process one item at a time. 2. how to remove a specific item This will ease the monitoring of what's in the replication queues and also to use queues as the buffer to pull items from a remote instance. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3480) Adding test for replication config delete
[ https://issues.apache.org/jira/browse/SLING-3480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3480: --- Component/s: (was: Extensions) Replication Labels: (was: replication) Adding test for replication config delete - Key: SLING-3480 URL: https://issues.apache.org/jira/browse/SLING-3480 Project: Sling Issue Type: Test Components: Replication Reporter: Marius Petria Assignee: Tommaso Teofili Priority: Minor Attachments: SLING-3480.patch Adding test for replication config delete and also fixing the test for config create, -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3327) Remove packages after being processed
[ https://issues.apache.org/jira/browse/SLING-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3327: --- Component/s: (was: Extensions) Replication Labels: (was: replication) Remove packages after being processed - Key: SLING-3327 URL: https://issues.apache.org/jira/browse/SLING-3327 Project: Sling Issue Type: Improvement Components: Replication Reporter: Marius Petria Assignee: Tommaso Teofili Attachments: SLING-3327.patch After a replication package it is used cleanup the resources it occupied. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3309) Allow flushing of external caching systems
[ https://issues.apache.org/jira/browse/SLING-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3309: --- Component/s: (was: Extensions) Replication Labels: (was: replication) Allow flushing of external caching systems -- Key: SLING-3309 URL: https://issues.apache.org/jira/browse/SLING-3309 Project: Sling Issue Type: Improvement Components: Replication Reporter: Marius Petria Assignee: Tommaso Teofili Attachments: SLING-3309.1.patch, SLING-3309.patch Allow signaling over HTTP to external caching systems that a content hierarchy has changed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3672) Sling Jobs based queue looks always empty
[
https://issues.apache.org/jira/browse/SLING-3672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili updated SLING-3672:
---
Component/s: (was: Extensions)
Replication
Labels: (was: replication)
Sling Jobs based queue looks always empty
-
Key: SLING-3672
URL: https://issues.apache.org/jira/browse/SLING-3672
Project: Sling
Issue Type: Bug
Components: Replication
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
When using Sling Event 3.3.10 calling {code}MapString,Object props = new
HashMapString,Object();
CollectionJob jobs = jobManager.findJobs(QueryType.QUEUED, topic, -1,
props);{code} returns no jobs even if there are, therefore queues using Sling
Jobs always look empty as this code is used in ReplicationQueue#getHead.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (SLING-3300) Add an API to create replication agent (configuration)
[ https://issues.apache.org/jira/browse/SLING-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3300: --- Component/s: (was: Extensions) Replication Labels: (was: replication) Add an API to create replication agent (configuration) -- Key: SLING-3300 URL: https://issues.apache.org/jira/browse/SLING-3300 Project: Sling Issue Type: Improvement Components: Replication Reporter: Tommaso Teofili Assignee: Bertrand Delacretaz Attachments: SLING-3300.patch, SLING-3300.patch Other than retrieving and updating configuration of an agent it's a common need to be able to create an agent configuration (and therefore the agent itself) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3816) Use the same flow of operations for forward and reverse replication
[ https://issues.apache.org/jira/browse/SLING-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3816: --- Component/s: (was: Extensions) Replication Labels: (was: replication) Use the same flow of operations for forward and reverse replication --- Key: SLING-3816 URL: https://issues.apache.org/jira/browse/SLING-3816 Project: Sling Issue Type: Improvement Components: Replication Reporter: Marius Petria Assignee: Tommaso Teofili Attachments: SLING-3816.patch Current replication code treats differently the forward and reverse replication. Forward replication creates a content package, adds it to a queue and transports it to the other instance while reverse replication creates a dummy POLL package, transports it to the other instance, retrieves the result queues it and then installs it in the current instance. The current flow for reverse replication complicates the code structure and can be simplified by using three main entities: 1. Package Importers: can import(install) a replication package 1.a ReplicationPackageImporter 1.b ReplicationPackageImporterServlet bound to replication/importer resource type 1.c http://localhost:4502/libs/sling/replication/importers.json 2. Package Exporters - can export (create) a replication package 2.a ReplicationPackageExporter 2.b ReplicationPackageExporterServlet bound to replication/exporter resource type 2.c http://localhost:4502/libs/sling/replication/exporters.json 3. Replication Agents - coordinate the interaction between an exporter and an importer using the following flow: exports a package, adds it to a queue, and the imports the package. 3.a ReplicationAgent 3.b ReplicationAgentServlet bound to replication/agent resource type 3.c http://localhost:4502/libs/sling/replication/agents.json Basically for forward replication the exporter is local and the importer is remote while for reverse replication the difference is that the exporter is remote and the importer is local. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3295) Add a scheduled replication rule
[ https://issues.apache.org/jira/browse/SLING-3295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3295: --- Component/s: (was: Extensions) Replication Labels: (was: replication) Add a scheduled replication rule Key: SLING-3295 URL: https://issues.apache.org/jira/browse/SLING-3295 Project: Sling Issue Type: Improvement Components: Replication Reporter: Tommaso Teofili Assignee: Bertrand Delacretaz Attachments: SLING-3295.patch To schedule replication agents actions on certain paths every X seconds it'd be good to have a dedicated replication rule, using Sling Scheduler -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3553) Run FindBugs (and fix accordingly) on Sling Replication code
[ https://issues.apache.org/jira/browse/SLING-3553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3553: --- Component/s: (was: Extensions) Replication Labels: (was: replication) Run FindBugs (and fix accordingly) on Sling Replication code Key: SLING-3553 URL: https://issues.apache.org/jira/browse/SLING-3553 Project: Sling Issue Type: Improvement Components: Replication Reporter: Tommaso Teofili Assignee: Tommaso Teofili Priority: Trivial Sling Replication code has grown over time and I'd like to a) fix current problems as reported by FindBugs b) add a reporting entry to the pom.xml in order to be continuously able to check eventual problems. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3315) Refactor replication HTTP API
[
https://issues.apache.org/jira/browse/SLING-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili updated SLING-3315:
---
Component/s: (was: Extensions)
Replication
Labels: (was: replication)
Refactor replication HTTP API
-
Key: SLING-3315
URL: https://issues.apache.org/jira/browse/SLING-3315
Project: Sling
Issue Type: Improvement
Components: Replication
Reporter: Marius Petria
Assignee: Tommaso Teofili
Attachments: SLING-3315.1.patch, SLING-3315.2.patch, SLING-3315.patch
Refactor HTTP API in order to access independently the configuration of an
agent and the service API for an agent. This was needed because there are
times when a configuration can exist without an agent being available (e.g.
when the agent is not disabled).
Proposed API:
Managing configuration
POST /system/replication/config/agent (creates and agent cofig)
GET /system/replication/config/agent (retrieves all agents config)
POST /system/replication/config/agent/{agentName} (updates and agent)
GET /system/replication/config/agent/{agentName} (retrieves the agent
config)
DELETE /system/replication/config/agent/{agentName} (deletes an agent config)
Managing agent
POST /system/replication/agent/{agentName} (schedules a package for
replication or removes one from the queue)
GET /system/replication/agent/{agentName}/queue (lists the packages in
the queue)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (SLING-3311) Add facilities to monitor replication status
[ https://issues.apache.org/jira/browse/SLING-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3311: --- Component/s: (was: Extensions) Replication Labels: (was: replication) Add facilities to monitor replication status Key: SLING-3311 URL: https://issues.apache.org/jira/browse/SLING-3311 Project: Sling Issue Type: Improvement Components: Replication Reporter: Tommaso Teofili It'd be good to have one or more ways of monitoring the status of replication agents / queues / etc. Possible (not mutually exclusive) ways of doing that include: JMX, Sling HealthChecks, HTTP Monitoring API. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3280) Remove old agents in agents directory
[ https://issues.apache.org/jira/browse/SLING-3280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3280: --- Component/s: (was: Extensions) Replication Labels: (was: replication) Remove old agents in agents directory - Key: SLING-3280 URL: https://issues.apache.org/jira/browse/SLING-3280 Project: Sling Issue Type: Task Components: Replication Reporter: Tommaso Teofili Assignee: Bertrand Delacretaz Attachments: SLING-3280.patch Agent configurations in SLING-CONTENT/libs/sling/replication/agents should be removed as they were split into SLING-CONTENT/libs/sling/replication/configuration/[author|publish] as part of SLING-3265 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3395) Event based reverse replication
[ https://issues.apache.org/jira/browse/SLING-3395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3395: --- Component/s: (was: Extensions) Replication Labels: (was: replication) Event based reverse replication --- Key: SLING-3395 URL: https://issues.apache.org/jira/browse/SLING-3395 Project: Sling Issue Type: Improvement Components: Replication Reporter: Tommaso Teofili Assignee: Tommaso Teofili Currently polling from remote instances can be done periodically via a schedule rule. An improved design would allow the poller to get notifications about when a new item to poll is available. Implementation wise this can be done via Websocket, Server Sent Events, Long Poll, etc. since it allows the polling instance to establish the connection and the polled instance to signal events there (like a command channel) asynchronously and let reverse replication happen only when needed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3336) Add ability to replicate to multiple enpoints
[ https://issues.apache.org/jira/browse/SLING-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3336: --- Component/s: (was: Extensions) Replication Labels: (was: replication) Add ability to replicate to multiple enpoints - Key: SLING-3336 URL: https://issues.apache.org/jira/browse/SLING-3336 Project: Sling Issue Type: Improvement Components: Replication Reporter: Marius Petria Assignee: Tommaso Teofili Attachments: SLING-3336.patch Add ability to replicate to multiple endpoints in order to support broadcasting in a clustered environment. The implementation should also have a configurable strategy (broadcast to all or just to one in the cluster). It should support also polling from multiple sources. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3356) Expose the import queue for reverse replication through ReplicationAgent interface
[ https://issues.apache.org/jira/browse/SLING-3356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3356: --- Component/s: (was: Extensions) Replication Labels: (was: replication) Expose the import queue for reverse replication through ReplicationAgent interface -- Key: SLING-3356 URL: https://issues.apache.org/jira/browse/SLING-3356 Project: Sling Issue Type: Improvement Components: Replication Reporter: Marius Petria Assignee: Tommaso Teofili Attachments: SLING-3356.1.patch, SLING-3356.2.patch, SLING-3356.3.patch, SLING-3356.patch The replication agent should have 3 main queues (the request queue, the transport queue and the response queue). These queues should be accessible and manageable through ReplicationAgent interface. This issue relates to the implementation of the response queue inside the ReplicationAgent and making it accessible through ReplicationAgent.getQueue API. The response queue is the queue where reverse replication on author stores packages from publish. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3223) Donation of a replication module for Sling
[ https://issues.apache.org/jira/browse/SLING-3223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3223: --- Component/s: (was: Extensions) Replication Labels: (was: replication) Donation of a replication module for Sling -- Key: SLING-3223 URL: https://issues.apache.org/jira/browse/SLING-3223 Project: Sling Issue Type: Task Components: Replication Reporter: Tommaso Teofili Assignee: Bertrand Delacretaz Attachments: SLING-3223.patch Issue to track donation of a replication module for Sling. Discussion thread: http://markmail.org/thread/ic62k5pc34ppb5ko Vote on dev@sling thread: http://markmail.org/thread/scz5arlfs5rgowg2 Result vote on dev@sling: http://markmail.org/thread/ix7s4fzvsdwmxrpk -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3669) Fix wrong /system/replication endpoints in http and poll transport configs
[ https://issues.apache.org/jira/browse/SLING-3669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3669: --- Component/s: (was: Extensions) Replication Fix wrong /system/replication endpoints in http and poll transport configs -- Key: SLING-3669 URL: https://issues.apache.org/jira/browse/SLING-3669 Project: Sling Issue Type: Bug Components: Replication Reporter: Tommaso Teofili Assignee: Tommaso Teofili Priority: Trivial HttpTransportHandlerFactory-http-publish-receive and PollingTransportHandlerFactory-http-publish-poll configurations hold an old reference to /system/replication/... endpoints which should be changed to /libs/sling/replication/... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3668) Avoid NPE in FileVaultReplicationPackage due to missing File for VLT package
[ https://issues.apache.org/jira/browse/SLING-3668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3668: --- Component/s: (was: Extensions) Replication Avoid NPE in FileVaultReplicationPackage due to missing File for VLT package Key: SLING-3668 URL: https://issues.apache.org/jira/browse/SLING-3668 Project: Sling Issue Type: Bug Components: Replication Reporter: Tommaso Teofili Assignee: Tommaso Teofili Priority: Trivial FileVaultReplicationPackage should not throw NPE when asked for the ID when the VLT package is not backed by a File. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3549) PollingTransportHandler should log connection errors
[ https://issues.apache.org/jira/browse/SLING-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3549: --- Component/s: (was: Extensions) Replication PollingTransportHandler should log connection errors Key: SLING-3549 URL: https://issues.apache.org/jira/browse/SLING-3549 Project: Sling Issue Type: Improvement Components: Replication Reporter: Tommaso Teofili Assignee: Tommaso Teofili Priority: Minor PollingTransportHandler currently throws an Exception if it's unable to establish a connection to the endpoint instance however it'd be better to log the problem and go ahead, as that would allow to remove the useless polling request from the queue which would instead stay. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3548) Replication queue servlet doesn't use the queue parameter
[ https://issues.apache.org/jira/browse/SLING-3548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3548: --- Component/s: (was: Extensions) Replication Replication queue servlet doesn't use the queue parameter - Key: SLING-3548 URL: https://issues.apache.org/jira/browse/SLING-3548 Project: Sling Issue Type: Bug Components: Replication Reporter: Tommaso Teofili Assignee: Tommaso Teofili Priority: Trivial ReplicationQueueServlet gets but never uses an HTTP parameter to name the queue to be fetched, so that the default one is always returned. -- This message was sent by Atlassian JIRA (v6.2#6252)
[RT] Multi Tenancy
Hi,
we've seen a lot of different dicsussions over time wrt multi tenancy in
this list. In addition, there is the age old proposal at [1] and the tenant
module in [2] which superceeds parts of the proposal on the wiki
The current tenant module detects the tenant of a request either based on
the requested content path or the user home and provides this information
via an adapter factory for both, the resource resolver and a resource.
While this mechanism might not be sufficient, I think the key point here is
that you get the tenant by adapting the resource resolver - which actually
allows to do any detection being it path based, or based on the url, a
cookie whatever. In that sense, it seems that this design is sufficient.
When it comes to content, structuring content by tenant and using ACLs to
protect this seems to be sufficient as well.
Now, the tricky and yet unsolved part is resource and script resolution.
The idea outlined in [1] is imho obsolete because we now already have
tenant support.
I think we can add tenant support to resource resolving and script
resolution without any further api changes: both implementation can try to
adapt the resource resolver to a Tenant and then the resource resolver
implementation can use this extra information for lookups. The script
resolver uses the resource resolver anyway, the only thing needed to be
added there is that caching of script resolution should take the tenant
into account.
My suggestion is that, if the Tenant information is availabe, resource
resolving looks at three places. For example if foo/bar should be
resolved:
1. /tenants/{tenandId}/foo/bar
2. /apps/foo/bar
3. /libs/foo/bar
The first available will be used.
I think there is no need for several search paths per tenant or to make
this further configurable
WDYT?
Regards
Carsten
[1] https://cwiki.apache.org/confluence/display/SLING/Multitenancy+Support
[2] https://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/tenant
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
[jira] [Resolved] (SLING-3747) Provide a way to signal Jcr Installer to pause and resume scanning
[
https://issues.apache.org/jira/browse/SLING-3747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved SLING-3747.
Resolution: Fixed
Assignee: Chetan Mehrotra
Implemented the above logic in http://svn.apache.org/r1617254
The logic would check for presence of any child node in path
{{/system/sling/installer/jcr/pauseInstallation}} (default value) as an
indicator that JCR integration should be paused. If no child is found the
normal processing would be done
Provide a way to signal Jcr Installer to pause and resume scanning
--
Key: SLING-3747
URL: https://issues.apache.org/jira/browse/SLING-3747
Project: Sling
Issue Type: New Feature
Components: Installer
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Fix For: JCR Installer 3.1.8
Attachments: SLING-3747-1.patch, SLING-3747-2.patch, SLING-3747.patch
Currently Sling Installer JCR Provider would listen for observation event and
would perform a rescan every 500 msec upon receiving any observation event.
This at times cause issue when large number of bundles get updated in
repository say via installation of bug fixing content package. Further if
same content package also updates the repository bundle then it causes issues
as repository bundle might get updated midway while content package is still
being deployed
Based on [~fmeschbe] suggestion this can be done via introducing a signalling
mechanism between component which installs package and JCR Installer. It
would work something like this
# JCR Installer would listen to changes done to property
{{/system/sling/installer/jcr/pauseInstallation}}
# Package installer would set the above flag to true before installing the
package and reset it back to false post installation
# If JCR Installer detects that flag is set to true it would not scan the
watch folders untill it get reset back to false
This should also address the issue in cluster deployment
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (SLING-3747) Provide a way to signal Jcr Installer to pause and resume scanning
[
https://issues.apache.org/jira/browse/SLING-3747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated SLING-3747:
---
Description:
Currently Sling Installer JCR Provider would listen for observation event and
would perform a rescan every 500 msec upon receiving any observation event.
This at times cause issue when large number of bundles get updated in
repository say via installation of bug fixing content package. Further if same
content package also updates the repository bundle then it causes issues as
repository bundle might get updated midway while content package is still being
deployed
Based on [~fmeschbe] suggestion this can be done via introducing a signalling
mechanism between component which installs package and JCR Installer. It would
work something like this
# JCR Installer would check if there is any node under
{{/system/sling/installer/jcr/pauseInstallation}} as a signal to pause
installation.
# Package installer would create a child node under the above path before
installing the package and remove it post installation
This should also address the issue in cluster deployment
was:
Currently Sling Installer JCR Provider would listen for observation event and
would perform a rescan every 500 msec upon receiving any observation event.
This at times cause issue when large number of bundles get updated in
repository say via installation of bug fixing content package. Further if same
content package also updates the repository bundle then it causes issues as
repository bundle might get updated midway while content package is still being
deployed
Based on [~fmeschbe] suggestion this can be done via introducing a signalling
mechanism between component which installs package and JCR Installer. It would
work something like this
# JCR Installer would listen to changes done to property
{{/system/sling/installer/jcr/pauseInstallation}}
# Package installer would set the above flag to true before installing the
package and reset it back to false post installation
# If JCR Installer detects that flag is set to true it would not scan the watch
folders untill it get reset back to false
This should also address the issue in cluster deployment
Provide a way to signal Jcr Installer to pause and resume scanning
--
Key: SLING-3747
URL: https://issues.apache.org/jira/browse/SLING-3747
Project: Sling
Issue Type: New Feature
Components: Installer
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Fix For: JCR Installer 3.1.8
Attachments: SLING-3747-1.patch, SLING-3747-2.patch, SLING-3747.patch
Currently Sling Installer JCR Provider would listen for observation event and
would perform a rescan every 500 msec upon receiving any observation event.
This at times cause issue when large number of bundles get updated in
repository say via installation of bug fixing content package. Further if
same content package also updates the repository bundle then it causes issues
as repository bundle might get updated midway while content package is still
being deployed
Based on [~fmeschbe] suggestion this can be done via introducing a signalling
mechanism between component which installs package and JCR Installer. It
would work something like this
# JCR Installer would check if there is any node under
{{/system/sling/installer/jcr/pauseInstallation}} as a signal to pause
installation.
# Package installer would create a child node under the above path before
installing the package and remove it post installation
This should also address the issue in cluster deployment
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (SLING-3836) Allow deep vs shallow replication options
Marius Petria created SLING-3836: Summary: Allow deep vs shallow replication options Key: SLING-3836 URL: https://issues.apache.org/jira/browse/SLING-3836 Project: Sling Issue Type: Improvement Components: Replication Reporter: Marius Petria Users of replication should have a way to choose whether to replicate a node - deep: including all its subtree - shallow: including just he node properties Typically an user editing content visually will trigger a replication of only the edited content (shallow). However an user importing a lot of content will trigger a deep replication after all content is imported. Shallow replication is more targeted and produces the least changes in the system and it is probably best fitted to be the default replication option. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3709) Sling Models: Allow caller to deal with exceptions
[ https://issues.apache.org/jira/browse/SLING-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14092704#comment-14092704 ] Konrad Windszus commented on SLING-3709: I enriched the PR to also use the same mechanism for instanciating submodels. The ValidationException for now will stay as is. Later on we can improve that. Sling Models: Allow caller to deal with exceptions -- Key: SLING-3709 URL: https://issues.apache.org/jira/browse/SLING-3709 Project: Sling Issue Type: Improvement Affects Versions: Sling Models Implementation 1.0.4, Sling Models Implementation 1.0.6 Reporter: Konrad Windszus Currently due to the specification of the adaptTo-method to return null if adaptation is not possible, the caller is not notified about any exceptions (because they are caught within the ModelAdapterFactory). This is e.g. necessary to deal with validation exceptions properly (i.e. required field injection not possible). The problem was also discussed briefly in http://apache-sling.73963.n3.nabble.com/Silng-Models-Validation-Framework-td4033411.html. All exceptions either being thrown by the @PostConstruct method or caused by the field/method injection are not propagated but basically swallowed by Sling Models. It would be great to be able to catch those exceptions either in the view or in a servlet filter. I think it should be possible to throw unchecked exceptions in the ModelAdapterFactory.getFactory() method if it is requested (i.e. through a global OSGi configuration flag for Sling Models). WDYT? Would you accept such a patch or do you think this breaks the API (also compare with https://issues.apache.org/jira/browse/SLING-2712?focusedCommentId=13561516page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13561516). If it does not work through the adaptTo, SlingModels should provide an alternative way of instanciating models (and propagating exceptions), although this is kind of tricky, because it internally relies on adaptTo as well (e.g. in https://github.com/apache/sling/blob/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L647) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (SLING-3399) OOME in JcrResourceListener for many events
[
https://issues.apache.org/jira/browse/SLING-3399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig resolved SLING-3399.
--
Resolution: Won't Fix
Assignee: Michael Dürig
Resolving as won't fix as the {{OakResourceListner}} from SLING-3279 should be
used when running into this problem.
OOME in JcrResourceListener for many events
---
Key: SLING-3399
URL: https://issues.apache.org/jira/browse/SLING-3399
Project: Sling
Issue Type: Bug
Components: JCR
Affects Versions: JCR Resource 2.3.0
Reporter: Michael Dürig
Assignee: Michael Dürig
Oak supports large number of transient changes to be saved with a single save
call. As a consequence such an operation will generate a big batch of
observation events, which can cause the JcrResourceListener to run out of
heap space.
See also SLING-3279 where I already noted that queueing observation events
might be problematic.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SLING-3836) Allow deep vs shallow replication options
[ https://issues.apache.org/jira/browse/SLING-3836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14092718#comment-14092718 ] Marius Petria commented on SLING-3836: -- There are two options to implement this. At the level of replication API or as a configuration of the package exporter. - API based: Add a property (isDeep) to ReplicationRequest that lets the agent know what the intention is. - Configuration based: An agent can be configured to replicate all requests deep or shallow. A client will have to use two separate agents for replicating deep or shallow. It is worth thinking how such options should be treated in general. We might need to add options for synchronous replication, or even more complex tree replication (always replicating jcr:content for pages). Allow deep vs shallow replication options - Key: SLING-3836 URL: https://issues.apache.org/jira/browse/SLING-3836 Project: Sling Issue Type: Improvement Components: Replication Reporter: Marius Petria Labels: replication Users of replication should have a way to choose whether to replicate a node - deep: including all its subtree - shallow: including just he node properties Typically an user editing content visually will trigger a replication of only the edited content (shallow). However an user importing a lot of content will trigger a deep replication after all content is imported. Shallow replication is more targeted and produces the least changes in the system and it is probably best fitted to be the default replication option. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3837) Have a way to distribute replication configs across instances
[ https://issues.apache.org/jira/browse/SLING-3837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marius Petria updated SLING-3837: - Summary: Have a way to distribute replication configs across instances (was: Have a way such that replication configs can be distributed across instances) Have a way to distribute replication configs across instances - Key: SLING-3837 URL: https://issues.apache.org/jira/browse/SLING-3837 Project: Sling Issue Type: Improvement Components: Replication Reporter: Marius Petria Labels: replication Define and implement the necessary mechanisms for distributing replication configs. Replication configs (agents, importers, exporters) should be editable on one instance and the distributed to the other relevant instances. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3837) Have a way to distribute replication configs across instances
[ https://issues.apache.org/jira/browse/SLING-3837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14092726#comment-14092726 ] Marius Petria commented on SLING-3837: -- This can be done by using replication itself if: 1. we have already a configured setting 2. configs are saved as content 3. configs saved as content are available via http in a secure way. Currently, 2-3 are not satisfied. Osgi configs are exposed via http by a custom resourceprovider and they do not have a well defined content location. Have a way to distribute replication configs across instances - Key: SLING-3837 URL: https://issues.apache.org/jira/browse/SLING-3837 Project: Sling Issue Type: Improvement Components: Replication Reporter: Marius Petria Labels: replication Define and implement the necessary mechanisms for distributing replication configs. Replication configs (agents, importers, exporters) should be editable on one instance and the distributed to the other relevant instances. -- This message was sent by Atlassian JIRA (v6.2#6252)
RE: [RT] Multi Tenancy
hello carsten.
thanks for bringing this up. multi-tenancy is very important for our projects.
but to be honest, until now i did not see that any of the current tenant api
implementation [2] is of much use for user usecases.
let's start with the detecting of a tenant:
* if adapting from a resource resolver, detection by user is done. but this
implies that every user is exactly assigned to one tenant, which is - at least
in our projects - not always the case. there are always users that have access
to multiple tenants, controlled via ACLs. so this is not a 1:1 relation, but a
1-to-many relation.
* if adapting from a resource a path-based detection is used. here i do not
fully understand which path is meant - the path to the content of the tenant
(e.g. /content/*), or the path to custom scripts used in script resolution
(comparable to /apps/*). i do not get the distinction from your RT as well -
you refer only to the script resolution part. but if adapting from a resource,
this is usually a content resource, not a resource pointing to a script.
in my opinion both is relevant - to be able to connect one or multiple subtrees
in the content resource hierarchy with a specific tenant, and to allow to
provide tenant-specific script overlays.
in a 1:1 releation user-tenant the content dependency could be modeled via
ACLs, but if you have one user that can access multiple tenants this does not
work.
besides this for our usecases the option to provide tenant-specific script
resources has no high prio. much more importance is the possibility to create
tenant-specific configuration. this may apply OSGi services, which currently
support only one global configuration (ore one per runmode combination). on the
other side this applies to other application-specific business logic which
should behave differently from site to site or from tenant to tenant.
btw. we should perhaps first start to define what we mean with the term
tenant. this much-used and overloaded term might be a source of confusion as
well. in my view a tenant is in its smallest form e.g. one site (homepage and
all content pages below), perhaps plus a separate area for media assets. but a
tenant can also be a huge entity consisting of a lot of sites and other
content. because even for a huge tenant there might be the need for different
configuration for different sites/areas of the content we are currently
thinking if we even need support for nested tenants, which allow a
configuration parameter inheritance between the inner and outer tenants, up to
the global level of OSGi configurations.
for the configuration topic perhaps a separate RT should be started, but it's
closely related to a tenant concept.
stefan
-Original Message-
From: Carsten Ziegeler [mailto:cziege...@apache.org]
Sent: Monday, August 11, 2014 1:18 PM
To: dev@sling.apache.org
Subject: [RT] Multi Tenancy
Hi,
we've seen a lot of different dicsussions over time wrt multi tenancy in
this list. In addition, there is the age old proposal at [1] and the tenant
module in [2] which superceeds parts of the proposal on the wiki
The current tenant module detects the tenant of a request either based on
the requested content path or the user home and provides this information
via an adapter factory for both, the resource resolver and a resource.
While this mechanism might not be sufficient, I think the key point here is
that you get the tenant by adapting the resource resolver - which actually
allows to do any detection being it path based, or based on the url, a
cookie whatever. In that sense, it seems that this design is sufficient.
When it comes to content, structuring content by tenant and using ACLs to
protect this seems to be sufficient as well.
Now, the tricky and yet unsolved part is resource and script resolution.
The idea outlined in [1] is imho obsolete because we now already have
tenant support.
I think we can add tenant support to resource resolving and script
resolution without any further api changes: both implementation can try to
adapt the resource resolver to a Tenant and then the resource resolver
implementation can use this extra information for lookups. The script
resolver uses the resource resolver anyway, the only thing needed to be
added there is that caching of script resolution should take the tenant
into account.
My suggestion is that, if the Tenant information is availabe, resource
resolving looks at three places. For example if foo/bar should be
resolved:
1. /tenants/{tenandId}/foo/bar
2. /apps/foo/bar
3. /libs/foo/bar
The first available will be used.
I think there is no need for several search paths per tenant or to make
this further configurable
WDYT?
Regards
Carsten
[1] https://cwiki.apache.org/confluence/display/SLING/Multitenancy+Support
[2] https://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/tenant
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
Jenkins build is back to stable : sling-trunk-1.7 #746
See https://builds.apache.org/job/sling-trunk-1.7/746/changes
Jenkins build is back to stable : sling-trunk-1.7 » Apache Sling Launchpad Testing #746
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.launchpad.testing/746/
Jenkins build is still unstable: sling-trunk-1.8 » Apache Sling Resource Resolver #31
See https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.resourceresolver/31/
Jenkins build is still unstable: sling-trunk-1.8 » Apache Sling Launchpad Testing #31
See https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.launchpad.testing/31/
Jenkins build is still unstable: sling-trunk-1.8 #31
See https://builds.apache.org/job/sling-trunk-1.8/changes
Re: [RT] Multi Tenancy
Hi, On Mon, Aug 11, 2014 at 3:13 PM, Stefan Seifert sseif...@pro-vision.de wrote: ...btw. we should perhaps first start to define what we mean with the term tenant. this much-used and overloaded term might be a source of confusion as well... Definitely - I suggest creating a page under https://cwiki.apache.org/confluence/display/SLING for multi-tenant use cases and definitions. -Bertrand
[jira] [Commented] (SLING-3833) Cleanup ReplicationAgent interface and ReplicationAgentConfiguration
[ https://issues.apache.org/jira/browse/SLING-3833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14092758#comment-14092758 ] Tommaso Teofili commented on SLING-3833: patch applied, thanks Marius Cleanup ReplicationAgent interface and ReplicationAgentConfiguration Key: SLING-3833 URL: https://issues.apache.org/jira/browse/SLING-3833 Project: Sling Issue Type: Improvement Components: Replication Reporter: Marius Petria Assignee: Tommaso Teofili Attachments: SLING-3833.patch ReplicationAgent should have a minimal interface. More specifically a client should be able to schedule a ReplicationRequest and to visualize the ReplicationQueues. If we decide that synchronous execution is needed then that should be properly implemented as the current version is not synchronous. Also, agent configuration is particular to the SimpleReplicationAgent implementation. It is true that it is the single implementation that we have but it cannot be an API unless we decide on a fixed set of properties that all agent implementations should have. Either way configurations are currently accessible through the custom resource provider. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (SLING-3833) Cleanup ReplicationAgent interface and ReplicationAgentConfiguration
[ https://issues.apache.org/jira/browse/SLING-3833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved SLING-3833. Resolution: Fixed Cleanup ReplicationAgent interface and ReplicationAgentConfiguration Key: SLING-3833 URL: https://issues.apache.org/jira/browse/SLING-3833 Project: Sling Issue Type: Improvement Components: Replication Reporter: Marius Petria Assignee: Tommaso Teofili Attachments: SLING-3833.patch ReplicationAgent should have a minimal interface. More specifically a client should be able to schedule a ReplicationRequest and to visualize the ReplicationQueues. If we decide that synchronous execution is needed then that should be properly implemented as the current version is not synchronous. Also, agent configuration is particular to the SimpleReplicationAgent implementation. It is true that it is the single implementation that we have but it cannot be an API unless we decide on a fixed set of properties that all agent implementations should have. Either way configurations are currently accessible through the custom resource provider. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [RT] Multi Tenancy
On Mon, Aug 11, 2014 at 3:29 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: ...I suggest creating a page under https://cwiki.apache.org/confluence/display/SLING for multi-tenant use cases and definitions... There's already https://cwiki.apache.org/confluence/display/SLING/Multitenancy+Support but as Carsten says we do have a tenant API now. Like Stefan I'm just suspecting people have different ideas about what multi-tenancy means, so having use cases would help. -Bertrand
Re: [RT] Multi Tenancy
Hi Stefan, thanks for sharing your thoughts, 2014-08-11 15:13 GMT+02:00 Stefan Seifert sseif...@pro-vision.de: let's start with the detecting of a tenant: * if adapting from a resource resolver, detection by user is done. but this implies that every user is exactly assigned to one tenant, which is - at least in our projects - not always the case. there are always users that have access to multiple tenants, controlled via ACLs. so this is not a 1:1 relation, but a 1-to-many relation. Right, this is how the implementation currently works - the nice thing is that this is abstracted behind the adaptTo call, so it can easily be replaced with something totally different. * if adapting from a resource a path-based detection is used. here i do not fully understand which path is meant - the path to the content of the tenant (e.g. /content/*), or the path to custom scripts used in script resolution (comparable to /apps/*). i do not get the distinction from your RT as well - you refer only to the script resolution part. but if adapting from a resource, this is usually a content resource, not a resource pointing to a script. I think in this case, adapting from a content resource is meant. To be honest, I'm not sure if this is a good idea anyway - but the good thing is - as above - it's abstracted. Personally I would skip this adaption and just go with resource resolver. in my opinion both is relevant - to be able to connect one or multiple subtrees in the content resource hierarchy with a specific tenant, and to allow to provide tenant-specific script overlays. in a 1:1 releation user-tenant the content dependency could be modeled via ACLs, but if you have one user that can access multiple tenants this does not work. I think, the way I wanted it actually to describe is, that there is a 1:1 relation between a request and a tenant. All tenant aware components simply adapt the resource resolver to Tenant and get the tenant. Regardless of how the mapping is done. besides this for our usecases the option to provide tenant-specific script resources has no high prio. much more importance is the possibility to create tenant-specific configuration. this may apply OSGi services, which currently support only one global configuration (ore one per runmode combination). on the other side this applies to other application-specific business logic which should behave differently from site to site or from tenant to tenant. Right, the use cases we have are per tenant scripts right now :) But I totally agree that per tenant OSGi configuration/bundles etc would be nice. A broad answer to this would be subsystems - although I'm not sure if it would help in all cases. btw. we should perhaps first start to define what we mean with the term tenant. this much-used and overloaded term might be a source of confusion as well. in my view a tenant is in its smallest form e.g. one site (homepage and all content pages below), perhaps plus a separate area for media assets. but a tenant can also be a huge entity consisting of a lot of sites and other content. because even for a huge tenant there might be the need for different configuration for different sites/areas of the content we are currently thinking if we even need support for nested tenants, which allow a configuration parameter inheritance between the inner and outer tenants, up to the global level of OSGi configurations. for the configuration topic perhaps a separate RT should be started, but it's closely related to a tenant concept. Right, it's overloaded. I think the wikipedia definition at [1] is what we mean. Although this needs to be mapped to Sling powered application. In our case we need partitioning of content, resource resolving and script resolution. With fully multi tenant support this would include OSGi configs and bundles. So, this would fit your site definition even for large sites. [1] http://en.wikipedia.org/wiki/Multitenancy Regards Carsten stefan -Original Message- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: Monday, August 11, 2014 1:18 PM To: dev@sling.apache.org Subject: [RT] Multi Tenancy Hi, we've seen a lot of different dicsussions over time wrt multi tenancy in this list. In addition, there is the age old proposal at [1] and the tenant module in [2] which superceeds parts of the proposal on the wiki The current tenant module detects the tenant of a request either based on the requested content path or the user home and provides this information via an adapter factory for both, the resource resolver and a resource. While this mechanism might not be sufficient, I think the key point here is that you get the tenant by adapting the resource resolver - which actually allows to do any detection being it path based, or based on the url, a cookie whatever. In that sense, it seems that this design is sufficient. When it comes to content, structuring content by
Jenkins build is back to stable : sling-trunk-1.6 » Apache Sling Launchpad Testing #2369
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/2369/
Jenkins build is back to stable : sling-trunk-1.6 #2369
See https://builds.apache.org/job/sling-trunk-1.6/2369/changes
[VOTE RESULT] Sling Auth Modules
Vote passed with three binding +1 votes Carsten 2014-08-09 0:41 GMT+02:00 Mike Müller mike...@mysign.ch: +1 Best regards mike -Original Message- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: Friday, August 08, 2014 2:26 PM To: dev@sling.apache.org Subject: [VOTE] Sling Auth Modules Hi, in order to get Launchpad 7 out, this is a vote to release Auth Core 1.1.8 https://issues.apache.org/jira/browse/SLING/fixforversion/12326055 Auth Selector 1.0.6 https://issues.apache.org/jira/browse/SLING/fixforversion/12316095 Form Based Autentication 1.0.6 https://issues.apache.org/jira/browse/SLING/fixforversion/12324551 OpenID Authentication 1.0.4 https://issues.apache.org/jira/browse/SLING/fixforversion/12315994 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1089 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 1089 /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. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [RT] Multi Tenancy
for us the goal would be to run multiple customers in one sling instance without the ability to touch the code/content of any other tenant. It would be nice if a) restricting users from one tennat to another would be simple b) allow a good search path override for each tenant c) split out the admin account into tenants (an admin session should not have access to all tenants) d) osgi properties per tenant (probably needs to be handled in felix?) Ruben On 8/11/2014 6:29 AM, Bertrand Delacretaz wrote: Hi, On Mon, Aug 11, 2014 at 3:13 PM, Stefan Seifert sseif...@pro-vision.de wrote: ...btw. we should perhaps first start to define what we mean with the term tenant. this much-used and overloaded term might be a source of confusion as well... Definitely - I suggest creating a page under https://cwiki.apache.org/confluence/display/SLING for multi-tenant use cases and definitions. -Bertrand
[jira] [Closed] (SLING-3488) Redirect after authentication breaks with context path
[ https://issues.apache.org/jira/browse/SLING-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-3488. --- Redirect after authentication breaks with context path -- Key: SLING-3488 URL: https://issues.apache.org/jira/browse/SLING-3488 Project: Sling Issue Type: Bug Components: Authentication Affects Versions: Auth Core 1.1.6 Reporter: Felix Oghină Assignee: Carsten Ziegeler Fix For: Auth Core 1.1.8 Attachments: patch.diff Specifying a sling.auth.redirect parameter in an authentication request is broken if running with a context path: * if the parameter value doesn't contain the context path it's rejected as invalid and the request is redirected to /contextpath * if the parameter value contains the contextpath it is duplicated in the redirect, so the request is redirected to /contextpath/contextpath/... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (SLING-3794) Fields for dynamic references must be volatile
[ https://issues.apache.org/jira/browse/SLING-3794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-3794. --- Fields for dynamic references must be volatile -- Key: SLING-3794 URL: https://issues.apache.org/jira/browse/SLING-3794 Project: Sling Issue Type: Bug Components: Authentication Affects Versions: Auth Core 1.1.6 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Auth Core 1.1.8 The fields for dynamic references must be declared as volatile -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (SLING-3795) Fields for dynamic references must be volatile
[ https://issues.apache.org/jira/browse/SLING-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-3795. --- Fields for dynamic references must be volatile -- Key: SLING-3795 URL: https://issues.apache.org/jira/browse/SLING-3795 Project: Sling Issue Type: Bug Components: Authentication Affects Versions: Form Based Authentication 1.0.4 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Form Based Authentication 1.0.6 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (SLING-3378) SelectorFormServlet should escape auth type
[ https://issues.apache.org/jira/browse/SLING-3378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-3378. --- SelectorFormServlet should escape auth type --- Key: SLING-3378 URL: https://issues.apache.org/jira/browse/SLING-3378 Project: Sling Issue Type: Bug Components: Authentication Affects Versions: Auth Selector 1.0.4 Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor Fix For: Auth Selector 1.0.6 The SelectorFormServlet should escape the selectedAuthType request parameter that it uses. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (SLING-3443) Parameter based redirection in FormAuthenticationHandler should not handle absolute urls
[ https://issues.apache.org/jira/browse/SLING-3443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-3443. --- Parameter based redirection in FormAuthenticationHandler should not handle absolute urls Key: SLING-3443 URL: https://issues.apache.org/jira/browse/SLING-3443 Project: Sling Issue Type: Bug Components: Authentication Affects Versions: Form Based Authentication 1.0.2 Reporter: Ravi Teja Assignee: Carsten Ziegeler Priority: Critical Fix For: Form Based Authentication 1.0.6 Original Estimate: 48h Remaining Estimate: 48h Suppose your login url is: http://blah/blah?resource=http://www.google.com Then after login succeeds, user would be redirected to http://www.google.com Will be submitting a pull request for this. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (SLING-2293) Call to RelyingParty.newInstance() should be wraped in TCCL reset block
[ https://issues.apache.org/jira/browse/SLING-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-2293. --- Call to RelyingParty.newInstance() should be wraped in TCCL reset block --- Key: SLING-2293 URL: https://issues.apache.org/jira/browse/SLING-2293 Project: Sling Issue Type: Improvement Components: Authentication Reporter: Justin Edelson Assignee: Justin Edelson Fix For: OpenID Authentication 1.0.4 The code inside dyu's RelyingParty.newInstance() method uses the Thread Context Classloader. We should wrap this call with some TCCL switching. -- This message was sent by Atlassian JIRA (v6.2#6252)
Jenkins build is still unstable: sling-oak-it-1.6 » Apache Sling Launchpad Testing #63
See https://builds.apache.org/job/sling-oak-it-1.6/org.apache.sling$org.apache.sling.launchpad.testing/63/
Jenkins build is still unstable: sling-oak-it-1.6 #63
See https://builds.apache.org/job/sling-oak-it-1.6/63/
[jira] [Created] (SLING-3838) Cleanup log.isLevelEnabled log statements where not needed
Tommaso Teofili created SLING-3838:
--
Summary: Cleanup log.isLevelEnabled log statements where not needed
Key: SLING-3838
URL: https://issues.apache.org/jira/browse/SLING-3838
Project: Sling
Issue Type: Improvement
Components: Replication
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
Priority: Minor
Replication code has many is{Info|Debug|Warn}Enabled statements that are mostly
not needed (as they are not in loops nor using any string concatenation) and
thus should be removed.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Jenkins build is still unstable: sling-trunk-1.8 » Apache Sling Launchpad Testing #32
See https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.launchpad.testing/32/
[jira] [Commented] (SLING-3838) Cleanup log.isLevelEnabled log statements where not needed
[
https://issues.apache.org/jira/browse/SLING-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14092820#comment-14092820
]
Tommaso Teofili commented on SLING-3838:
fixed in r1617297
Cleanup log.isLevelEnabled log statements where not needed
--
Key: SLING-3838
URL: https://issues.apache.org/jira/browse/SLING-3838
Project: Sling
Issue Type: Improvement
Components: Replication
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
Priority: Minor
Replication code has many is{Info|Debug|Warn}Enabled statements that are
mostly not needed (as they are not in loops nor using any string
concatenation) and thus should be removed.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (SLING-3838) Cleanup log.isLevelEnabled log statements where not needed
[
https://issues.apache.org/jira/browse/SLING-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili resolved SLING-3838.
Resolution: Fixed
Cleanup log.isLevelEnabled log statements where not needed
--
Key: SLING-3838
URL: https://issues.apache.org/jira/browse/SLING-3838
Project: Sling
Issue Type: Improvement
Components: Replication
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
Priority: Minor
Replication code has many is{Info|Debug|Warn}Enabled statements that are
mostly not needed (as they are not in loops nor using any string
concatenation) and thus should be removed.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Jenkins build is still unstable: sling-trunk-1.8 » Apache Sling Resource Resolver #32
See https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.resourceresolver/32/
Jenkins build is still unstable: sling-trunk-1.8 #32
See https://builds.apache.org/job/sling-trunk-1.8/changes
RE: [RT] Multi Tenancy
when looking in the wiki i found another page [1] with some thoughts on multi tenancy from a mailing list discussion from february [2] from this i get we have two quite different scenarios although they have a shared part: * the fully isolated tenant scenario - tenants are fully isolated and have their own script (overlay) path, own users, own i18n etc. - as described in [1] - the existing tenant implementation targets on this scenario as well, but does currently fulfill only part of the requirements from [1] * the manage multiple tenants scenario - a set of users (editors, admins etc.) manages a set of tenants with n-to-m relation between users and tenants - providing script overlays and admin separation is not that important, but configuration and content separation it think both scenarios can be handled with a single (flexible/customizable) implementation, but both have their own complexities not relevant for the other. so when starting a wiki page we have to respect both scenarios. stefan [1] https://cwiki.apache.org/confluence/display/SLING/Multitenancy+Support+Integration [2] http://apache-sling.73963.n3.nabble.com/Tenant-Implementation-in-Sling-td4031217.html#none -Original Message- From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] Sent: Monday, August 11, 2014 3:32 PM To: Bertrand Delacretaz Cc: dev Subject: Re: [RT] Multi Tenancy On Mon, Aug 11, 2014 at 3:29 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: ...I suggest creating a page under https://cwiki.apache.org/confluence/display/SLING for multi-tenant use cases and definitions... There's already https://cwiki.apache.org/confluence/display/SLING/Multitenancy+Support but as Carsten says we do have a tenant API now. Like Stefan I'm just suspecting people have different ideas about what multi-tenancy means, so having use cases would help. -Bertrand
[jira] [Created] (SLING-3839) Reorganize ReplicationPackage related API in a single java package
Marius Petria created SLING-3839: Summary: Reorganize ReplicationPackage related API in a single java package Key: SLING-3839 URL: https://issues.apache.org/jira/browse/SLING-3839 Project: Sling Issue Type: Improvement Components: Replication Reporter: Marius Petria Currently ReplicationPackage APIs and implementations are split between serialization and transport. We need to unify this under packaging and keep the internal subpackages serialization and transport for utils APIs. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3839) Reorganize ReplicationPackage related API in a single java package
[ https://issues.apache.org/jira/browse/SLING-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marius Petria updated SLING-3839: - Attachment: SLING-3839.patch Reorganize ReplicationPackage related API in a single java package -- Key: SLING-3839 URL: https://issues.apache.org/jira/browse/SLING-3839 Project: Sling Issue Type: Improvement Components: Replication Reporter: Marius Petria Labels: replication Attachments: SLING-3839.patch Currently ReplicationPackage APIs and implementations are split between serialization and transport. We need to unify this under packaging and keep the internal subpackages serialization and transport for utils APIs. -- This message was sent by Atlassian JIRA (v6.2#6252)
Jenkins build is still unstable: sling-oak-it-1.6 » Apache Sling Launchpad Testing #64
See https://builds.apache.org/job/sling-oak-it-1.6/org.apache.sling$org.apache.sling.launchpad.testing/64/
Jenkins build is still unstable: sling-oak-it-1.6 #64
See https://builds.apache.org/job/sling-oak-it-1.6/64/
Jenkins build became unstable: sling-trunk-1.7 » Apache Sling Resource-Based Discovery Service #748
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.discovery.impl/748/
Jenkins build became unstable: sling-trunk-1.7 #748
See https://builds.apache.org/job/sling-trunk-1.7/748/changes
Jenkins build became unstable: sling-trunk-1.8 » Apache Sling Models Integration Tests #33
See https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.models.integration-tests/33/
Jenkins build is still unstable: sling-trunk-1.8 » Apache Sling Resource Resolver #33
See https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.resourceresolver/33/
Jenkins build is still unstable: sling-trunk-1.8 » Apache Sling Launchpad Testing #33
See https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.launchpad.testing/33/
Jenkins build is still unstable: sling-trunk-1.8 #33
See https://builds.apache.org/job/sling-trunk-1.8/changes
Jenkins build became unstable: sling-trunk-1.6 » Apache Sling JCR Installer #2371
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.installer.provider.jcr/2371/
Jenkins build became unstable: sling-trunk-1.6 » Apache Sling Launchpad Base #2371
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.base/2371/
Jenkins build became unstable: sling-trunk-1.6 #2371
See https://builds.apache.org/job/sling-trunk-1.6/2371/changes
Re: [VOTE] Release Apache Sling Query version 2.0.0
+1 Robert On Fri, Aug 8, 2014 at 3:23 PM, Carsten Ziegeler cziege...@apache.org wrote: +1 2014-08-08 13:54 GMT+02:00 Robert Munteanu romb...@apache.org: On Fri, Aug 8, 2014 at 2:33 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Fri, Aug 8, 2014 at 12:46 PM, Robert Munteanu romb...@apache.org wrote: ...There are still some outstanding issues: https://issues.apache.org/jira/browse/SLING/component/12312240 FWIW I don't see any Sling Query issues in that list, that's the generic extensions component. Good point. Many modules don't have their own component. Should we just drop this link where it doesn't make sense? Robert -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [RT] Multi Tenancy
On 11.08.2014, at 06:13, Stefan Seifert sseif...@pro-vision.de wrote: btw. we should perhaps first start to define what we mean with the term tenant. this much-used and overloaded term might be a source of confusion as well. in my view a tenant is in its smallest form e.g. one site (homepage and all content pages below), perhaps plus a separate area for media assets. Yes. Already today you can have multiple sites/projects/tenants by using different resource types: /apps/project1/components/foo /apps/project2/components/foo and this is really the same as /apps/tenant1/components/foo /apps/tenant2/components/foo And then use the resource types in the content: /content/tenant1/site/@sling:resourceType = tenant1/components/foo The next question is then probably how to avoid tenant1 can use code of tenant2? And here it becomes tricky. Because if you are allowed to write arbitrary code (e.g. in JSPs), you can get an admin session, and thus do what you want anyway. So enforcing to set the right resource types in the first place (e.g. UIs not allowing you to choose templates / components from another tenant) have the same level of security then a complex tenant script resolution mechanism. Shielding custom code from different tenants essentially will require a JVM that can do that properly, of which only an IBM one can do it AFAIK. OSGi itself won't really offer a safe shielding - even subsystems are just there for simpler deployment configuration of groups that belong together, not for security. Also, in general you want to minimize the parts that have to know about the actual tenants. Most code should just read content / resources, look up configurations which are absolute or relative paths (such as the resource types pointing from /content/tenant1 to /apps/tenant1 or a configuration reference from /content/tenant1 to /etc/tenant1) and handle them transparently. ACLs enforce access to it, e.g. all tenant1 users have access to /content/tenant1, /apps/tenant1 (although this is special since servlet resolution is done using a special user) and /etc/tenant1. This leaves the part that needs to know about actual tenants to a minimum - the management of creating a new tenant (which can be just a template of content + ACLs + users/groups), deleting it etc. And it decouples specific application code from knowing the exact tenant structure, which could be different in different scenarios, and most importantly, it avoids being constrained to a single level such as /apps/tenant1 and allows nested project hiearchies such as /apps/tenant1/subtenant/project1. IMHO servlet resolution is one such application code part that shouldn't know about it. In essence, I would be very careful in adding a new complexity such as tenant based resolution. Cheers, Alex
