[jira] [Commented] (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:comment-tabpanelfocusedCommentId=13896305#comment-13896305 ] Tommaso Teofili commented on SLING-3356: Marius, thanks for your patch, I however don't seem to be able to apply it, maybe it was not created against latest trunk? Could you try making it work with it? (I tried both patch -p0 and patch -p1). 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: Extensions Reporter: Marius Petria Assignee: Tommaso Teofili Labels: replication Attachments: 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.1.5#6160)
[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 ] Marius Petria updated SLING-3356: - Attachment: SLING-3356.1.patch Fixing patch to be based on latest trunk 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: Extensions Reporter: Marius Petria Assignee: Tommaso Teofili Labels: replication Attachments: SLING-3356.1.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.1.5#6160)
release for org.apache.sling.maven-sling-plugin
Hello, Can someone please release the new org.apache.sling.maven-sling-plugin (2.1.2)? In my build process I would like to rely on this plugin to correctly fail the build if the bundle was not installed on the instance (see [0]). Thanks, Radu [0] - https://github.com/apache/sling/commit/771615f20ec9c269d0c8cb7c75db3bb06719a369
[jira] [Created] (SLING-3384) Simplify AbstractSlingRepository implementation
Felix Meschberger created SLING-3384: Summary: Simplify AbstractSlingRepository implementation Key: SLING-3384 URL: https://issues.apache.org/jira/browse/SLING-3384 Project: Sling Issue Type: New Feature Components: JCR Affects Versions: JCR Base 2.1.2, JCR Jackrabbit Server 2.1.0 Reporter: Felix Meschberger Assignee: Felix Meschberger With the introduction of the SlingRepository.loginService method the existing setup of the AbstractSlingRepository became quite complex in that it hacks in a SlingRepository proxy to be able to register the SlingRepository as a service and implement the new method. An additional problem of the AbstractSlingRepository class is that it expects the implementation to be implemented using Declarative Services. While this was simple and easy in the beginning it created a runtime dependency which does not go well with the OSGi framework. So, I propose to create a new couple of (abstract) classes which simplify the setup and implementation of SlingRepository services. Another feature of the original AbstractSlingRepository base class was access to foreign repositories as well as repository pinging which turns out to be functionality not being usefull in an abstract base class. Rather this would be something in an actual implementation which knows how to deal with such pre-existing foreign repository instances. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SLING-3384) Simplify AbstractSlingRepository implementation
[
https://issues.apache.org/jira/browse/SLING-3384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896368#comment-13896368
]
Felix Meschberger commented on SLING-3384:
--
First steps in Rev. 1566547:
* Deprecated AbstractSlingRepository and AbstractNamespaceMappingRepository
* Created new AbstractSlingRepositoryManager and NamespaceMappingSupport base
classes. These are used to implement a JCR repository instance manager: A
single JCR repository instance backs subsequent repository services.
* Created a new AbstractSlingRepository2 base class with basic implementations
of all Repository and SlingRepository methods. Extensions of this class
basically just overwrite a single method {{createAdministrativeSession}} but
may, of course, overwrite all methods according to the contracts defined in the
AbstractSlingRepository2 class.
Repository polling and access to external repositories (by way of some URL
properties) as implemented by the AbstractSlingRepository class is not
implemented in the new classes. IMHO such polling and external repository
access is not something that belongs in an abstract base class.
Simplify AbstractSlingRepository implementation
---
Key: SLING-3384
URL: https://issues.apache.org/jira/browse/SLING-3384
Project: Sling
Issue Type: New Feature
Components: JCR
Affects Versions: JCR Jackrabbit Server 2.1.0, JCR Base 2.1.2
Reporter: Felix Meschberger
Assignee: Felix Meschberger
With the introduction of the SlingRepository.loginService method the existing
setup of the AbstractSlingRepository became quite complex in that it hacks in
a SlingRepository proxy to be able to register the SlingRepository as a
service and implement the new method.
An additional problem of the AbstractSlingRepository class is that it expects
the implementation to be implemented using Declarative Services. While this
was simple and easy in the beginning it created a runtime dependency which
does not go well with the OSGi framework.
So, I propose to create a new couple of (abstract) classes which simplify the
setup and implementation of SlingRepository services.
Another feature of the original AbstractSlingRepository base class was
access to foreign repositories as well as repository pinging which turns
out to be functionality not being usefull in an abstract base class. Rather
this would be something in an actual implementation which knows how to deal
with such pre-existing foreign repository instances.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (SLING-3384) Simplify AbstractSlingRepository implementation
[ https://issues.apache.org/jira/browse/SLING-3384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896374#comment-13896374 ] Felix Meschberger commented on SLING-3384: -- Adapted the Jackrabbit Server bundle to the new AbstractSlingRepositoryManager and AbstractSlingRepository2 classes in Rev. 1566551. Simplify AbstractSlingRepository implementation --- Key: SLING-3384 URL: https://issues.apache.org/jira/browse/SLING-3384 Project: Sling Issue Type: New Feature Components: JCR Affects Versions: JCR Jackrabbit Server 2.1.0, JCR Base 2.1.2 Reporter: Felix Meschberger Assignee: Felix Meschberger With the introduction of the SlingRepository.loginService method the existing setup of the AbstractSlingRepository became quite complex in that it hacks in a SlingRepository proxy to be able to register the SlingRepository as a service and implement the new method. An additional problem of the AbstractSlingRepository class is that it expects the implementation to be implemented using Declarative Services. While this was simple and easy in the beginning it created a runtime dependency which does not go well with the OSGi framework. So, I propose to create a new couple of (abstract) classes which simplify the setup and implementation of SlingRepository services. Another feature of the original AbstractSlingRepository base class was access to foreign repositories as well as repository pinging which turns out to be functionality not being usefull in an abstract base class. Rather this would be something in an actual implementation which knows how to deal with such pre-existing foreign repository instances. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SLING-3384) Simplify AbstractSlingRepository implementation
[ https://issues.apache.org/jira/browse/SLING-3384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896376#comment-13896376 ] Felix Meschberger commented on SLING-3384: -- Also adapted the Oak Server bundle in Rev. 1566553 Simplify AbstractSlingRepository implementation --- Key: SLING-3384 URL: https://issues.apache.org/jira/browse/SLING-3384 Project: Sling Issue Type: New Feature Components: JCR Affects Versions: JCR Jackrabbit Server 2.1.0, JCR Base 2.1.2 Reporter: Felix Meschberger Assignee: Felix Meschberger With the introduction of the SlingRepository.loginService method the existing setup of the AbstractSlingRepository became quite complex in that it hacks in a SlingRepository proxy to be able to register the SlingRepository as a service and implement the new method. An additional problem of the AbstractSlingRepository class is that it expects the implementation to be implemented using Declarative Services. While this was simple and easy in the beginning it created a runtime dependency which does not go well with the OSGi framework. So, I propose to create a new couple of (abstract) classes which simplify the setup and implementation of SlingRepository services. Another feature of the original AbstractSlingRepository base class was access to foreign repositories as well as repository pinging which turns out to be functionality not being usefull in an abstract base class. Rather this would be something in an actual implementation which knows how to deal with such pre-existing foreign repository instances. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SLING-3384) Simplify AbstractSlingRepository implementation
[ https://issues.apache.org/jira/browse/SLING-3384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896381#comment-13896381 ] Felix Meschberger commented on SLING-3384: -- Adapted Repository integration tests in Rev. 1566562 -- basically updating bundle versions Simplify AbstractSlingRepository implementation --- Key: SLING-3384 URL: https://issues.apache.org/jira/browse/SLING-3384 Project: Sling Issue Type: New Feature Components: JCR Affects Versions: JCR Jackrabbit Server 2.1.0, JCR Base 2.1.2 Reporter: Felix Meschberger Assignee: Felix Meschberger With the introduction of the SlingRepository.loginService method the existing setup of the AbstractSlingRepository became quite complex in that it hacks in a SlingRepository proxy to be able to register the SlingRepository as a service and implement the new method. An additional problem of the AbstractSlingRepository class is that it expects the implementation to be implemented using Declarative Services. While this was simple and easy in the beginning it created a runtime dependency which does not go well with the OSGi framework. So, I propose to create a new couple of (abstract) classes which simplify the setup and implementation of SlingRepository services. Another feature of the original AbstractSlingRepository base class was access to foreign repositories as well as repository pinging which turns out to be functionality not being usefull in an abstract base class. Rather this would be something in an actual implementation which knows how to deal with such pre-existing foreign repository instances. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (SLING-3384) Simplify AbstractSlingRepository implementation
[ https://issues.apache.org/jira/browse/SLING-3384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896381#comment-13896381 ] Felix Meschberger edited comment on SLING-3384 at 2/10/14 10:22 AM: Adapted Repository integration tests in Rev. 1566562 and 1566565 -- basically updating bundle versions and adding the ServiceUserMapper was (Author: fmeschbe): Adapted Repository integration tests in Rev. 1566562 -- basically updating bundle versions Simplify AbstractSlingRepository implementation --- Key: SLING-3384 URL: https://issues.apache.org/jira/browse/SLING-3384 Project: Sling Issue Type: New Feature Components: JCR Affects Versions: JCR Jackrabbit Server 2.1.0, JCR Base 2.1.2 Reporter: Felix Meschberger Assignee: Felix Meschberger With the introduction of the SlingRepository.loginService method the existing setup of the AbstractSlingRepository became quite complex in that it hacks in a SlingRepository proxy to be able to register the SlingRepository as a service and implement the new method. An additional problem of the AbstractSlingRepository class is that it expects the implementation to be implemented using Declarative Services. While this was simple and easy in the beginning it created a runtime dependency which does not go well with the OSGi framework. So, I propose to create a new couple of (abstract) classes which simplify the setup and implementation of SlingRepository services. Another feature of the original AbstractSlingRepository base class was access to foreign repositories as well as repository pinging which turns out to be functionality not being usefull in an abstract base class. Rather this would be something in an actual implementation which knows how to deal with such pre-existing foreign repository instances. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
New AbstractSlingRepositoryManager base class (SLING-3384)
Hi all After a few years living with the AbstractSlingRepository base class, I though it would be about time for a simpler reimplementation to get rid of a few restrictions: - External repositories (see below) - Repository polling (see below) - Dependency on Declarative Services - Complex setup of ServiceFactory By introducing the new AbstractSlingRepositoryManager I was able to separate the actual OSGi service instance from the singleton repository. This makes the implementation as well as the extension a lot simpler: Basically it is a single method in the AbstractSlingRepository2 class and basically repository creation and shutdown in the AbstractSlingRepositoryManager class. This is also the time to get rid of one of the more complex parts of the AbstractsSlingRepository: External repository access and repository pinging. We have added both in early times of Sling, where we expected the repository to be available outside of Sling, e.g. in a different Web Application accessible through JNDI or even in an external system accessible through RMI or such. While there may well be setups leveraging these features, I would expect most deployments to use an embedded repository instance. Hence external repository access and repository pinging (to solve the non-existing livecycle support in LDAP and RMI setups) don't belong into this abstract base class. Rather they should be implemented in specialized bundles such as the Sling Jackrabbit Client bundle (in contrib). For now I have adapted the Jackrabbit Server and Oak Server bundle along with the Repository IT tests and the tests seem to run smoothly — except that on my box, the integration tests seem to block on the VanityPathTest Regards Felix [1] https://issues.apache.org/jira/browse/SLING-3384
[jira] [Created] (SLING-3385) Expose replication agents actions and information via HTTP.
Marius Petria created SLING-3385:
Summary: 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: Extensions
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.1.5#6160)
[jira] [Commented] (SLING-3045) [logback]Warning logs logged for 'No appenders present in context [sling] for logger'
[ https://issues.apache.org/jira/browse/SLING-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896459#comment-13896459 ] Chetan Mehrotra commented on SLING-3045: Updated the logic in [r1566597|http://svn.apache.org/r1566597] to be more robust [logback]Warning logs logged for 'No appenders present in context [sling] for logger' - Key: SLING-3045 URL: https://issues.apache.org/jira/browse/SLING-3045 Project: Sling Issue Type: Bug Components: Commons Affects Versions: Commons Log 4.0.0 Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Priority: Minor Fix For: Commons Log 4.0.0 Attachments: SLING-3045.patch During system startup at times following warning is seen --- 14:48:24,969 |-WARN in Logger[org.apache.sling.installer.core.impl.OsgiInstallerImpl] - No appenders present in context [sling] for logger [org.apache.sling.installer.core.impl.OsgiInstallerImpl]. --- Further some debug level logs are also seen during the startup -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=13896509#comment-13896509
]
Felix Meschberger commented on SLING-3385:
--
I have the impression you should define a proper REST-ful API addressing agents
and queues as resources ...
* Replicate:
{noformat}
POST /system/replication/agents/{agentName}
content=/content/mycontentaction={action}
{noformat}
* Status/Information
{noformat}
GET /system/replication/agents/{agentName}
GET /system/replication/queues/{queueName}
GET /system/replication/packages/{queueName}/{agentName}
{noformat}
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: Extensions
Reporter: Marius Petria
Labels: replication
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.1.5#6160)
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=13896606#comment-13896606
]
Marius Petria commented on SLING-3385:
--
Hi Felix,
You are right, that would probably be a nicer design, however there are some
issues with it.
1. We want to be able to replicate to multiple agents at once so that would be
done by posting to /agents with multiple X-replication-agent headers.
2. There seems to be no consensus on how to expose such an hierarchy via HTTP
(see [1]). I am trying to propose here a not so nice compromise.
More specifically exposing /system/replication/agents/{agentName} can be done
with a ResourceProvider or with a hierarchy of shadow nodes. While for agent
configuration the shadow nodes make some sense because they contain properties
of the configuration and they can be accessed via standard servlets (in
/etc/replication) for agent and queue actions/status a shadow hierarchy of
nodes will be very unnatural.
Basically the compromise solution is to create only the root node of the
hierarchy and use query params to filter the results.
[1] https://issues.apache.org/jira/browse/SLING-3352
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: Extensions
Reporter: Marius Petria
Labels: replication
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.1.5#6160)
[jira] [Comment Edited] (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:comment-tabpanelfocusedCommentId=13896606#comment-13896606
]
Marius Petria edited comment on SLING-3385 at 2/10/14 2:40 PM:
---
Hi Felix,
You are right, that would probably be a nicer design, however there are some
issues with it.
1. We want to be able to replicate to multiple agents at once so that would be
done by posting to /agents with multiple X-replication-agent headers.
2. There seems to be no consensus on how to expose such an hierarchy via HTTP
(see \[1\]). I am trying to propose here a not so nice compromise.
More specifically exposing /system/replication/agents/\{agentName\} can be done
with a ResourceProvider or with a hierarchy of shadow nodes. While for agent
configuration the shadow nodes make some sense because they contain properties
of the configuration and they can be accessed via standard servlets (in
/etc/replication) for agent and queue actions/status a shadow hierarchy of
nodes will be very unnatural.
Basically the compromise solution is to create only the root node of the
hierarchy and use query params to filter the results.
[1] https://issues.apache.org/jira/browse/SLING-3352
was (Author: mpetria):
Hi Felix,
You are right, that would probably be a nicer design, however there are some
issues with it.
1. We want to be able to replicate to multiple agents at once so that would be
done by posting to /agents with multiple X-replication-agent headers.
2. There seems to be no consensus on how to expose such an hierarchy via HTTP
(see [1]). I am trying to propose here a not so nice compromise.
More specifically exposing /system/replication/agents/{agentName} can be done
with a ResourceProvider or with a hierarchy of shadow nodes. While for agent
configuration the shadow nodes make some sense because they contain properties
of the configuration and they can be accessed via standard servlets (in
/etc/replication) for agent and queue actions/status a shadow hierarchy of
nodes will be very unnatural.
Basically the compromise solution is to create only the root node of the
hierarchy and use query params to filter the results.
[1] https://issues.apache.org/jira/browse/SLING-3352
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: Extensions
Reporter: Marius Petria
Labels: replication
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.1.5#6160)
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=13896810#comment-13896810
]
Tobias Bocanegra commented on SLING-3385:
-
I don't like the use of http headers to transport the information. this is
highly unusable for ajax clients and for debugging. And it might not go through
proxies.
also, is there a documentation how the REST (or let's call it HTTP) API looks
like? what are the parameters for? how is the error handling? what is the
payload? what is the response?
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: Extensions
Reporter: Marius Petria
Labels: replication
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.1.5#6160)
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=13896977#comment-13896977
]
Marius Petria commented on SLING-3385:
--
Hi Tobias,
There is no detailed spec as I wanted to fix first the general approach.
Basically requests use headers and a stream payload for packages. If we are to
drop headers then we could use multipart messages with jsons containing the
metadata (action, paths, agent) and octetstreams containing the package bytes.
However, when I was analyzing this option it made more sense to rely again on
standard servlets rather than implementing custom servlets to handle the
payload.
We could use purely JCR nodes that store requests and packages.
For replication actions (commands) one would store the content of a command and
a task (or event handler) would pick it up, pass it to the agent and then move
it to outbox.
{noformat}
/system/replication/commands/inbox
/system/replication/commands/outbox
{noformat}
For importing/exporting packages those could be uploaded/downloaded from their
corresponding boxes.
{noformat}
/system/replication/packages/inbox
/system/replication/packages/outbox
{noformat}
The only questions for this approach are:
- Is there a way in sling to get the the first element in the outbox using
orderby and pagination.
- We might still need to expose status information about agents (like inner
queues status). Should we do this by using a resourceprovider in order to avoid
empty agent nodes?
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: Extensions
Reporter: Marius Petria
Labels: replication
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.1.5#6160)
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=13897026#comment-13897026
]
Tommaso Teofili commented on SLING-3385:
The way it currently works is described in SLING-3315.
Why should we persist requests ? Package persistence should be already handled
by the _ReplicationPackageBuilder_, why should we explicitly persist them
separately?
I think this and SLING-3352 are part of the same discussion about the
replication HTTP API, with this one specific to HTTP API for triggering
replication actions
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: Extensions
Reporter: Marius Petria
Labels: replication
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.1.5#6160)
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=13897139#comment-13897139
]
Tobias Bocanegra commented on SLING-3385:
-
I'm not saying you should store the 'commands' in the content - IMO that's
nonsense. but avoid HTTP headers to transport any action or parameter. they
belong to the HTTP layer, not your application :-)
A better REST way would be to upload the package first, get a location URL, and
then issue the commands referring to the packages. this also mitigates the
multiple-agents problem a bit.
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: Extensions
Reporter: Marius Petria
Labels: replication
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.1.5#6160)
[jira] [Commented] (SLING-3322) Export additional mozilla rhino packages
[
https://issues.apache.org/jira/browse/SLING-3322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897562#comment-13897562
]
Chetan Mehrotra commented on SLING-3322:
Applied the patch in [566989|http://svn.apache.org/r1]. Also updated the
package exports to have versions
Earlier
{noformat}
org.apache.sling.scripting.javascript
org.mozilla.javascript
{noformat}
Now
{noformat}
org.apache.sling.scripting.javascript {version=0.1.0, imported-as=[0.1,1)}
org.mozilla.classfile {version=0.0.0.1_7R4,
imported-as=[0.0,1)}
org.mozilla.javascript{version=0.0.0.1_7R4}
org.mozilla.javascript.debug {version=0.0.0.1_7R4,
imported-as=[0.0,1)}
{noformat}
Export additional mozilla rhino packages
-
Key: SLING-3322
URL: https://issues.apache.org/jira/browse/SLING-3322
Project: Sling
Issue Type: Improvement
Components: Scripting
Affects Versions: Scripting JavaScript 2.0.12
Reporter: Rohit Kumar
Priority: Minor
Fix For: Scripting JavaScript 2.0.14
Attachments: Sling-3322.patch
Our project requires following rhino packages:
org.mozilla.classfile,
org.mozilla.javascript.debug
It would be better if Sling exposes them.
Attaching patch.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (SLING-3322) Export additional mozilla rhino packages
[ https://issues.apache.org/jira/browse/SLING-3322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-3322. Resolution: Fixed Fix Version/s: Scripting JavaScript 2.0.14 Assignee: Chetan Mehrotra Export additional mozilla rhino packages - Key: SLING-3322 URL: https://issues.apache.org/jira/browse/SLING-3322 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting JavaScript 2.0.12 Reporter: Rohit Kumar Assignee: Chetan Mehrotra Priority: Minor Fix For: Scripting JavaScript 2.0.14 Attachments: Sling-3322.patch Our project requires following rhino packages: org.mozilla.classfile, org.mozilla.javascript.debug It would be better if Sling exposes them. Attaching patch. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=13897589#comment-13897589
]
Felix Meschberger commented on SLING-3385:
--
I think [~tripod] hit the nail: You should be defining a concise REST-ful (or
HTTP if you will) API and discuss that. This really is an API discussion at
this point and we can think about the implementation later.
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: Extensions
Reporter: Marius Petria
Labels: replication
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.1.5#6160)
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=13897595#comment-13897595
]
Marius Petria commented on SLING-3385:
--
bq. avoid HTTP headers to transport any action or parameter
That will be done :).
bq. store the 'commands' in the content - IMO that's nonsense.
From what I found out that is the only secure way in sling to expose REST APIs
OOTB. Any servlet based approach (registered by path or by resourcetype) is
unsecure by default and must be protected inside the servlet.
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: Extensions
Reporter: Marius Petria
Labels: replication
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.1.5#6160)
