Re: JIRA access

[Felix Meschberger]

Hi

Or better yet, create new issues pertaining to concrete tests you add.

BTW: Thanks a lot for taking a stab. This is very much appreciated.

Regards
Felix

Am 09.10.2013 um 07:19 schrieb Bertrand Delacretaz:

> Hi,
> 
> On Wed, Oct 9, 2013 at 4:04 PM, David Moloney  wrote:
>> ...I was hoping to cut my teeth contributing to Sling by looking into 
>> integration
>> tests for SLING-999...
> 
> Cool!
> 
> AFAIK that's still relevant.
> 
>> Thought possibly I should request contributor access here, or should I
>> create a patch first & attach?...
> 
> You can create and attach a patch, and we can then grant you
> contributor status as needed.
> 
> Have fun!
> 
> -Bertrand



smime.p7s
Description: S/MIME cryptographic signature

Re: TopologyConnectorServlet

[Felix Meschberger]

Hi

Am 09.10.2013 um 09:05 schrieb Ian Boston:

> Hi,
> 
> On 9 October 2013 16:21, Felix Meschberger  wrote:
>> Hi
>> 
>> Am 08.10.2013 um 10:40 schrieb Ian Boston:
>> 
>>> Hi,
>>> The whitelist configuration in this servlet is causing some problems
>>> where the contents of the whitelist is potentially large and changing,
>>> since it requires constant re-configuration.
>> 
>> What is the problem with that ?
> 
> When the whitelist in the central discovery endpoint depends on the
> topology itself, it causes production deployment problems, especially
> when the configuration of the end point and the management of the
> topology of the production deployment are managed by different roles
> within the organisation. This is typical of many organisations.
> Engineers don't manage operations and TechOps don't manage
> engineering. Normally configuration would be managed by TechOps but

Fully agreed ! Which is exactly the reason why conceptually we have to separate 
development from deployment and which is why configuration *is* in fact a 
deployment issue and not a development issue.

> with Sling that doesn't appear to be the case.

How come ? That is not the intent of how Sling should be used.

> Consequently the 2 get
> out of sync, and if you are using Sling Discovery to transport
> metadata about your topology, lots of things start to break when nodes
> are not in the whitelist.

Sure, if developers want to be involved with deployment, things run havock.

> 
> In our special case we have 1 central discovery end point, if we had
> n, the problem would multiply by n.
> 
>> 
>> And why would a service API help mitigate that issue ?
> 
> It would give those that are able to see the deployment infrastructure
> that they are dealing with, the opportunity to address this issue.
> 
>> Considering that service would have to be reconfigured, too, and your code 
>> sample belows uses a static reference ?
> 
> AFAIK it uses an optional reference, satisfied by a implementation
> outside Sling. The snippet was written from memory directly into the
> email to communicate what I was trying to discuss. Its is not real
> code.
> 
>> 
>> Also, noted in another thread, this would require export of the API from the 
>> impl bundle, which I am not very happy with...
>> 
>> Finally -- and this is purely subjective -- I am not very happy with the 
>> name WhiteListProvider and then WhiteListProvider.isWhiteListed... Also 
>> would there be other needs for hooking into this servlet ?
>> 
> 
> I have been working on an implementation most of the day that is
> nothing like what was first discussed, I will commit in a moment. Much
> better to share real code with unit test coverage.

Ok.

Regards
Felix

> 
> Best Regards
> Ian
> 
> 
>> Regards
>> Felix
>> 
>> 
>> 
>>> 
>>> Would it be possible to have a API service that is consulted if
>>> present to check if the request is allowed. For those that want to use
>>> the service they would configure the whitelist to reject everything
>>> while the service was not present so avoid startup issues.
>>> 
>>> eg
>>> 
>>> +@Reference(cardinality=ReferenceCardinality.OPTIONAL_UNARY)
>>> + private WhiteListProvider   whiteListProvider;
>>> 
>>>   /** Checks if the provided request's remote server is whitelisted **/
>>> 
>>>   private boolean isWhitelisted(final SlingHttpServletRequest request) {
>>> +  if (whiteListProvider != null) {
>>> + whiteListProvider.isWhitelisted(request);
>>> +}
>>>   if (whitelist.contains(request.getRemoteAddr())) {
>>> 
>>>   return true;
>>> 
>>>   } else if (whitelist.contains(request.getRemoteHost())) {
>>> 
>>>   return true;
>>> 
>>>   }
>>> 
>>>   logger.info("isWhitelisted: rejecting " + request.getRemoteAddr()
>>> 
>>>   + ", " + request.getRemoteHost());
>>> 
>>>   return false;
>>> 
>>>   }
>>> 
>>> 
>>> and in the API, presumably discovery api.
>>> 
>>> public interface WhiteListProvider {
>>> 
>>>   private boolean isWhitelisted(HttpServletRequest request);
>>> 
>>> }
>>> 
>>> 
>>> Best Regards
>>> Ian
>> 



smime.p7s
Description: S/MIME cryptographic signature

Build failed in Jenkins: sling-trunk-1.7 #327

[Apache Jenkins Server]

See 

--
[...truncated 286 lines...]
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:679)
Caused by: hudson.scm.subversion.UpdaterException: failed to perform svn update
... 15 more
Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT 
/repos/asf/!svn/vcc/default failed
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:379)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:364)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:708)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:335)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1289)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:837)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:507)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274)
at 
org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27)
at 
org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11)
at 
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
at 
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:291)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387)
at 
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157)
... 14 more
Caused by: svn: E175002: REPORT /repos/asf/!svn/vcc/default failed
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97)
... 33 more
Caused by: org.tmatesoft.svn.core.SVNException: svn: E204899: REPORT request 
failed on '/repos/asf/!svn/vcc/default'
svn: E204899: Cannot create new file 
'/home/hudson/jenkins-slave/workspace/sling-trunk-1.7/trunk/samples/espblog/src/main/java/org/apache/sling/samples/espblog/.svn/lock'
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:748)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
... 32 more
Caused by: svn: E204899: REPORT request failed on '/repos/asf/!svn/vcc/default'
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97)
at org.tmatesoft.svn.core.SVNErrorMessage.wrap(SVNErrorMessage.java:407)
... 34 more
Caused by: svn: E204899: Cannot create new file 
'/home/hudson/jenkins-slave/workspace/sling-trunk-1.7/trunk/samples/espblog/src/main/java/org/apache/sling/samples/espblog/.svn/lock'
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:171)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:126)
at 
org.tmatesoft.svn.core.internal.wc.SVNFileUtil.createEmptyFile(SVNFileUtil.java:346)
at 
org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea14.createVersionedDirectory(SVNAdminArea14.java:1553)
at 
org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea16Factory.doCreateVersionedDirectory(SVNAdminArea16Factory.java:30)
at 
org.tmatesoft.svn.core.internal.wc.admin.SVNAdminAreaFactory.createVersionedDirectory(SVNAdminAreaFactory.java:241)
at 
org.tmatesoft.svn.core.internal.wc.SVNWCManager.ensureAdminAreaExists(SVNWCManager.java:428)
at 
org.tmatesoft.svn.core.internal.wc.SVNUpdateEditor.addDir(SVNUpdateEditor.java:762)
 

Jenkins build is back to stable : sling-trunk-1.6 » Apache Sling Launchpad Testing #1958

[Apache Jenkins Server]

See 

Jenkins build is back to normal : sling-trunk-1.6 #1958

[Apache Jenkins Server]

See 

Jenkins build is back to normal : sling-trunk-1.7 #326

[Apache Jenkins Server]

See 

[jira] [Commented] (SLING-3154) Add Topology Message Verification to the Discovery service.

[Ian Boston (JIRA)]

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

Ian Boston commented on SLING-3154:
---

Changes committed with code coverage for the new code for the passing use cases.
Verified no impact on current implementation, as none of the existing tests 
were touched.
All discovery bundles build and pass tests.
Will need to deploy so some live instances and configure to validate in the 
wild.

This is a brief description

Uses HmacSHA256 with a derived key that lasts 4h for signatures.
Uses AES/CBC/PKCS5Padding with a 128 bit key and random 9 byte salt for 
encryption if enabled.

Configuration is via the Config Component. To enable white listing is turned 
off, a shared key is set and optionally, encryption and the signature key 
lifetime is set.

Signature is performed by performing a HMAC on a SHA of the body, url and 
direction message (request or response). The SHA is put in X-SlingTopologyHash 
header, the HMAC is put in X-SlingTopologyTrust header.

Verifying the message can be trusted rebuilds checks that the HMAC of the SHA 
is the same as in the request. No reference is made to the body of the request. 

When extracting the body of the request or response the SHA is rebuilt and 
checked against the body of the message (encrypted if the body was encrypted)

Encryption takes the String body, and encrypts into a json object with a single 
key "payload" containing a JSONArray made up of the base64 encoded 10 byte 
salt, the Cipher initialisation vector as base64 encoded bytes, and the 
encrypted data.

Decryption uses the salt to generate the key and initialisation vector to 
decrypt the data.

It is possible to replay the same identical message 2x.
It is not possible to replay a different message using an old hash/hmac
It is not possible to replay an empty message (eg DELETE, where the body is 
null) on different urls.
Requests and responses do not share hash/hmac pairs and both directions are 
secured.

I will leave the issue open in case there objections to this change from the 
community or if testing turns up issues.



> Add Topology Message Verification to the Discovery service.
> ---
>
> Key: SLING-3154
> URL: https://issues.apache.org/jira/browse/SLING-3154
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Affects Versions: Discovery Impl 1.0.0
>Reporter: Ian Boston
>Assignee: Ian Boston
> Fix For: Discovery Impl 1.0.2
>
>
> The discovery service provides support for whitelisting sources of topology 
> information, but in a cluster where the topology this creates a 
> re-configuration load of order M*(n*(n-1)) where n is the number of nodes in 
> the topology and M is the number of changes. That load rises rapidly as the 
> number of changes and/or nodes increases. 
> To address this there are 2 proposals.
> 1. To provide an SPI exported from the Discovery Impl bundle that allows 
> implementors to implement whitelisting based on the request. This will need 
> to support creating the request and validating the request.
> 2. Embed functionality within the Discovery Impl bundle that supports 
> validation and encryption of topology requests.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Build failed in Jenkins: sling-trunk-1.6 #1957

[Apache Jenkins Server]

See 

Changes:

[cziegeler] SLING-3139 : Provide a way to schedule jobs

--
[...truncated 14595 lines...]
09.10.2013 14:15:50.098 *INFO* [main] org.apache.sling.event Service 
[org.apache.sling.event.impl.jobs.deprecated.JobStatusProviderImpl,95] 
ServiceEvent REGISTERED
09.10.2013 14:15:55.107 *WARN* [Apche Sling JCR Resource Event Queue Processor 
for path '/'] org.apache.felix.eventadmin EventAdmin: Blacklisting 
ServiceReference [[org.apache.sling.event.jobs.JobManager, 
org.osgi.service.event.EventHandler, 
org.apache.sling.discovery.TopologyEventListener, java.lang.Runnable] | 
Bundle(org.apache.sling.event [66])] due to timeout!
Build timed out (after 150 minutes). Marking the build as failed.

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: 
Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Reactor Summary:
Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: 
Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling JAR Resource Bundle .. SUCCESS [18.559s]
Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling (Parent) . SUCCESS [5.311s]
Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Adapter Annotations . SUCCESS [5.892s]
Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Maven Plugin to create Jackrabbit OCM descriptors  SUCCESS 
[4.932s]
Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Maven Plugin for Compiling JSP Sources into Bundles  SUCCESS 
[5.577s]
Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Maven Plugin for Supporting Bundle Development  SUCCESS 
[4.261s]
Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Launchpad Maven Plugin ... SUCCESS [19.476s]
Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Launchpad Standalone Archetype .. SUCCESS [4.601s]
Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Launchpad Webapp Archetype .. SUCCESS [3.246s]
Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Initial Content Archetype ... SUCCESS [3.020s]
Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Servlet Archetype ... SUCCESS [10.588s]
Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Bundle Archetype  SUCCESS [2.731s]
Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling JCRInstall Bundle Archetype . SUCCESS [7.749s]
Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Sling Taglib Archetype  SUCCESS [3.102s]
Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling API .. SUCCESS [9.748s]
Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Service User Mapper .. SUCCESS [5.600s]
Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Resource Resolver  SUCCESS [7.586s]
Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling System Bundle Extension: Java Transaction API  SUCCESS 
[2.981s]
Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling System Bundle Extension: XML APIs  SUCCESS [3.342s]
Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling System Bundle Extension: Activation API  SUCCESS [2.833s]
Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling System Bundle Extension: WS APIs . SUCCESS [2.987s]
Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger 
logReactorSummary
INFO: Apache Sling Dynamic Class Loader Support . SUCCESS [10.541s]
Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventL

[jira] [Commented] (SLING-3154) Add Topology Message Verification to the Discovery service.

[Ian Boston (JIRA)]

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

Ian Boston commented on SLING-3154:
---

Hi [~egli]
I need the ability to have a single shared configuration for an entire topology 
that allows automated and secure discovery of all active members of that 
topology without any whitelisting. That configuration should be static and not 
dependent on the topology itself or reference anything in the physical topology.

"Regarding encrypting/decrypting: do we have all the APIs on the Sling level 
for this?"

I might be missing something but last time I looked the JDK supported 
encrypting/decrypting. It may not have a huge range of algorithms, but 
HmacSHA256 and AES/CBC/PKCS5Padding is probably good enough for this.

I have working code that doesn't do anything to the existing IP whitelisting 
unless configured to be active.

Best Regards
Ian

> Add Topology Message Verification to the Discovery service.
> ---
>
> Key: SLING-3154
> URL: https://issues.apache.org/jira/browse/SLING-3154
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Affects Versions: Discovery Impl 1.0.0
>Reporter: Ian Boston
>Assignee: Ian Boston
> Fix For: Discovery Impl 1.0.2
>
>
> The discovery service provides support for whitelisting sources of topology 
> information, but in a cluster where the topology this creates a 
> re-configuration load of order M*(n*(n-1)) where n is the number of nodes in 
> the topology and M is the number of changes. That load rises rapidly as the 
> number of changes and/or nodes increases. 
> To address this there are 2 proposals.
> 1. To provide an SPI exported from the Discovery Impl bundle that allows 
> implementors to implement whitelisting based on the request. This will need 
> to support creating the request and validating the request.
> 2. Embed functionality within the Discovery Impl bundle that supports 
> validation and encryption of topology requests.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: TopologyConnectorServlet

[Ian Boston]

Hi,

On 9 October 2013 16:21, Felix Meschberger  wrote:
> Hi
>
> Am 08.10.2013 um 10:40 schrieb Ian Boston:
>
>> Hi,
>> The whitelist configuration in this servlet is causing some problems
>> where the contents of the whitelist is potentially large and changing,
>> since it requires constant re-configuration.
>
> What is the problem with that ?

When the whitelist in the central discovery endpoint depends on the
topology itself, it causes production deployment problems, especially
when the configuration of the end point and the management of the
topology of the production deployment are managed by different roles
within the organisation. This is typical of many organisations.
Engineers don't manage operations and TechOps don't manage
engineering. Normally configuration would be managed by TechOps but
with Sling that doesn't appear to be the case. Consequently the 2 get
out of sync, and if you are using Sling Discovery to transport
metadata about your topology, lots of things start to break when nodes
are not in the whitelist.

In our special case we have 1 central discovery end point, if we had
n, the problem would multiply by n.

>
> And why would a service API help mitigate that issue ?

It would give those that are able to see the deployment infrastructure
that they are dealing with, the opportunity to address this issue.

> Considering that service would have to be reconfigured, too, and your code 
> sample belows uses a static reference ?

AFAIK it uses an optional reference, satisfied by a implementation
outside Sling. The snippet was written from memory directly into the
email to communicate what I was trying to discuss. Its is not real
code.

>
> Also, noted in another thread, this would require export of the API from the 
> impl bundle, which I am not very happy with...
>
> Finally -- and this is purely subjective -- I am not very happy with the name 
> WhiteListProvider and then WhiteListProvider.isWhiteListed... Also would 
> there be other needs for hooking into this servlet ?
>

I have been working on an implementation most of the day that is
nothing like what was first discussed, I will commit in a moment. Much
better to share real code with unit test coverage.

Best Regards
Ian


> Regards
> Felix
>
>
>
>>
>> Would it be possible to have a API service that is consulted if
>> present to check if the request is allowed. For those that want to use
>> the service they would configure the whitelist to reject everything
>> while the service was not present so avoid startup issues.
>>
>> eg
>>
>> +@Reference(cardinality=ReferenceCardinality.OPTIONAL_UNARY)
>> + private WhiteListProvider   whiteListProvider;
>>
>>/** Checks if the provided request's remote server is whitelisted **/
>>
>>private boolean isWhitelisted(final SlingHttpServletRequest request) {
>> +  if (whiteListProvider != null) {
>> + whiteListProvider.isWhitelisted(request);
>> +}
>>if (whitelist.contains(request.getRemoteAddr())) {
>>
>>return true;
>>
>>} else if (whitelist.contains(request.getRemoteHost())) {
>>
>>return true;
>>
>>}
>>
>>logger.info("isWhitelisted: rejecting " + request.getRemoteAddr()
>>
>>+ ", " + request.getRemoteHost());
>>
>>return false;
>>
>>}
>>
>>
>> and in the API, presumably discovery api.
>>
>> public interface WhiteListProvider {
>>
>>private boolean isWhitelisted(HttpServletRequest request);
>>
>> }
>>
>>
>> Best Regards
>> Ian
>

Re: TopologyConnectorServlet

[Felix Meschberger]

Hi

Am 08.10.2013 um 10:40 schrieb Ian Boston:

> Hi,
> The whitelist configuration in this servlet is causing some problems
> where the contents of the whitelist is potentially large and changing,
> since it requires constant re-configuration.

What is the problem with that ?

And why would a service API help mitigate that issue ? Considering that service 
would have to be reconfigured, too, and your code sample belows uses a static 
reference ?

Also, noted in another thread, this would require export of the API from the 
impl bundle, which I am not very happy with...

Finally -- and this is purely subjective -- I am not very happy with the name 
WhiteListProvider and then WhiteListProvider.isWhiteListed... Also would there 
be other needs for hooking into this servlet ?

Regards
Felix
 


> 
> Would it be possible to have a API service that is consulted if
> present to check if the request is allowed. For those that want to use
> the service they would configure the whitelist to reject everything
> while the service was not present so avoid startup issues.
> 
> eg
> 
> +@Reference(cardinality=ReferenceCardinality.OPTIONAL_UNARY)
> + private WhiteListProvider   whiteListProvider;
> 
>/** Checks if the provided request's remote server is whitelisted **/
> 
>private boolean isWhitelisted(final SlingHttpServletRequest request) {
> +  if (whiteListProvider != null) {
> + whiteListProvider.isWhitelisted(request);
> +}
>if (whitelist.contains(request.getRemoteAddr())) {
> 
>return true;
> 
>} else if (whitelist.contains(request.getRemoteHost())) {
> 
>return true;
> 
>}
> 
>logger.info("isWhitelisted: rejecting " + request.getRemoteAddr()
> 
>+ ", " + request.getRemoteHost());
> 
>return false;
> 
>}
> 
> 
> and in the API, presumably discovery api.
> 
> public interface WhiteListProvider {
> 
>private boolean isWhitelisted(HttpServletRequest request);
> 
> }
> 
> 
> Best Regards
> Ian



smime.p7s
Description: S/MIME cryptographic signature

[jira] [Commented] (SLING-3154) Add Topology Message Verification to the Discovery service.

[Stefan Egli (JIRA)]

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

Stefan Egli commented on SLING-3154:


Hi [~ianeboston], 

not quite sure I follow you here. 

Whitelisting is already supported but if I understand the reason for this 
ticket correctly, then it was the limited nature of the current whitelisting 
feature which is not 'enough' - hence, an API (or SPI..) for doing custom 
whitelisting - as you suggested on the list - to me does make a lot of sense. 
Or asked differently: how would the whitelisting feature you require for your 
use case look like (that would be generalizable enough to be put in the 
discovery.impl)?

Regarding encrypting/decrypting: do we have all the APIs on the Sling level for 
this?

Cheers,
Stefan

> Add Topology Message Verification to the Discovery service.
> ---
>
> Key: SLING-3154
> URL: https://issues.apache.org/jira/browse/SLING-3154
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Affects Versions: Discovery Impl 1.0.0
>Reporter: Ian Boston
>Assignee: Ian Boston
> Fix For: Discovery Impl 1.0.2
>
>
> The discovery service provides support for whitelisting sources of topology 
> information, but in a cluster where the topology this creates a 
> re-configuration load of order M*(n*(n-1)) where n is the number of nodes in 
> the topology and M is the number of changes. That load rises rapidly as the 
> number of changes and/or nodes increases. 
> To address this there are 2 proposals.
> 1. To provide an SPI exported from the Discovery Impl bundle that allows 
> implementors to implement whitelisting based on the request. This will need 
> to support creating the request and validating the request.
> 2. Embed functionality within the Discovery Impl bundle that supports 
> validation and encryption of topology requests.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (SLING-3154) Add Topology Message Verification to the Discovery service.

[Ian Boston (JIRA)]

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

Ian Boston commented on SLING-3154:
---

I am thinking of a different approach.
Embed everything inside the discovery implementation (it is an implementation 
after all) and support whitelist or signing with optional encryption of the 
payload.

This should make it much simpler for anyone to configure.

Adding a SPI only becomes relevant if the internal impl doesn't cover whats 
needed, and if there is an SPI, then the impl becomes more complex.


> Add Topology Message Verification to the Discovery service.
> ---
>
> Key: SLING-3154
> URL: https://issues.apache.org/jira/browse/SLING-3154
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Affects Versions: Discovery Impl 1.0.0
>Reporter: Ian Boston
>Assignee: Ian Boston
> Fix For: Discovery Impl 1.0.2
>
>
> The discovery service provides support for whitelisting sources of topology 
> information, but in a cluster where the topology this creates a 
> re-configuration load of order M*(n*(n-1)) where n is the number of nodes in 
> the topology and M is the number of changes. That load rises rapidly as the 
> number of changes and/or nodes increases. 
> To address this there are 2 proposals.
> 1. To provide an SPI exported from the Discovery Impl bundle that allows 
> implementors to implement whitelisting based on the request. This will need 
> to support creating the request and validating the request.
> 2. Embed functionality within the Discovery Impl bundle that supports 
> validation and encryption of topology requests.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (SLING-3157) Launchpad bootstrap: prepare bundles for launchpad installer

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz resolved SLING-3157.


Resolution: Won't Fix

Not needed indeed, I have attached a patch to SLING-3155 that will enable run 
mode-based bundle selection.

> Launchpad bootstrap: prepare bundles for launchpad installer
> 
>
> Key: SLING-3157
> URL: https://issues.apache.org/jira/browse/SLING-3157
> Project: Sling
>  Issue Type: Improvement
>  Components: Launchpad
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> Once SLING-3156 is implemented we'll need to modify the launchpad bootstrap 
> code to copy the runmode-dependent bundles to where the launchpad installer 
> expects to find them.
> Currently, bundles found in the launchpad jar under paths like 
> resources/bundles.foo/5 (for runmode foo and run level 5) are ignored by the 
> bootstrap installer, we might just need to copy those to the right filesystem 
> folder.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (SLING-3156) Add bundles support to Launchpad installer

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz resolved SLING-3156.


Resolution: Won't Fix

Not needed indeed, I have attached a patch to SLING-3155 that will enable run 
mode-based bundle selection.

> Add bundles support to Launchpad installer
> --
>
> Key: SLING-3156
> URL: https://issues.apache.org/jira/browse/SLING-3156
> Project: Sling
>  Issue Type: Improvement
>  Components: Launchpad
>Affects Versions: Launchpad Installer 1.2.0
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>
> The launchpad installer currently supports only configurations, but for 
> SLING-3155 we need to provide runmode-dependent bundles to the OSGi installer.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (SLING-3155) Switch launchpad between Jackrabbit and Oak based on run modes

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated SLING-3155:
---

Attachment: SLING-3155.patch

Here's a first shot at a patch that installs only a minimal set of bundles via 
the bootstrap mechanism, and lets the OSGi installer install most bundles. The 
OSGi installer can then take run modes into account, which the bootstrap 
installer doesn't do.

This is not finished, see tODOs in the patch, but I won't be working on this in 
the next few days and I know [~asanso] is looking at the Oak stuff, so this 
patch might help if you want to finish this before I get back to it.

Also, with this patch the org.apache.sling.commons.log doesn't start, but 
starting it manually from the webconsole works.

> Switch launchpad between Jackrabbit and Oak based on run modes
> --
>
> Key: SLING-3155
> URL: https://issues.apache.org/jira/browse/SLING-3155
> Project: Sling
>  Issue Type: Improvement
>  Components: Launchpad
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
> Attachments: SLING-3155.patch
>
>
> We need this to run our integration tests on both Jackrabbit and Oak.
> Using -Dsling.run.modes=jackrabbit (or oak) on the first startup of the 
> launchpad runnable jar will switch.
> These run modes need to be set to be mutually exclusive and considered only 
> on the first startup, we don't support switching later. We'll need to support 
> upgrading a Jackrabbit repository to Oak but that's a different issue.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: JIRA access

[Bertrand Delacretaz]

Hi,

On Wed, Oct 9, 2013 at 4:04 PM, David Moloney  wrote:
> ...I was hoping to cut my teeth contributing to Sling by looking into 
> integration
> tests for SLING-999...

Cool!

AFAIK that's still relevant.

> Thought possibly I should request contributor access here, or should I
> create a patch first & attach?...

You can create and attach a patch, and we can then grant you
contributor status as needed.

Have fun!

-Bertrand

JIRA access

[David Moloney]

Hello everyone,

I was hoping to cut my teeth contributing to Sling by looking into integration 
tests for SLING-999. (If it's 
still a relevant issue? If not, I'd be happy to take a steer on something else).
I was just wondering the process — I've basic JIRA access, but can't assign the 
issue to myself. Thought possibly I should request contributor access here, or 
should I create a patch first & attach?

Best
Dave



Confidentiality notice
This communication is from LBi Ltd, a private limited company registered in 
Scotland with registered number SC177425 having its registered office at 51 
Timberbush, Edinburgh, EH6 6QH. DigitasLBi is a trading name of LBi Limited.
This electronic message contains information which may be privileged and 
confidential. The information is intended to be for the use of the 
individual(s) or entity named above. If you are not the intended recipient be 
aware that any disclosure, copying, distribution or use of the contents of this 
information is prohibited. If you have received this electronic message in 
error, please notify us by telephone or e-mail as above immediately.

Build failed in Jenkins: sling-trunk-1.7 #325

[Apache Jenkins Server]

See 

--
[...truncated 298 lines...]
Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT 
/repos/asf/!svn/vcc/default failed
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:379)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:364)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:708)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:335)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1289)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:837)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:507)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274)
at 
org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27)
at 
org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11)
at 
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
at 
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:291)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387)
at 
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157)
... 14 more
Caused by: svn: E175002: REPORT /repos/asf/!svn/vcc/default failed
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97)
... 33 more
Caused by: org.tmatesoft.svn.core.SVNException: svn: E204899: REPORT request 
failed on '/repos/asf/!svn/vcc/default'
svn: E204899: Cannot create new file 
'/home/hudson/jenkins-slave/workspace/sling-trunk-1.7/trunk/samples/espblog/src/main/java/org/apache/sling/samples/espblog/.svn/lock'
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:748)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
... 32 more
Caused by: svn: E204899: REPORT request failed on '/repos/asf/!svn/vcc/default'
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97)
at org.tmatesoft.svn.core.SVNErrorMessage.wrap(SVNErrorMessage.java:407)
... 34 more
Caused by: svn: E204899: Cannot create new file 
'/home/hudson/jenkins-slave/workspace/sling-trunk-1.7/trunk/samples/espblog/src/main/java/org/apache/sling/samples/espblog/.svn/lock'
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:171)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:126)
at 
org.tmatesoft.svn.core.internal.wc.SVNFileUtil.createEmptyFile(SVNFileUtil.java:346)
at 
org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea14.createVersionedDirectory(SVNAdminArea14.java:1553)
at 
org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea16Factory.doCreateVersionedDirectory(SVNAdminArea16Factory.java:30)
at 
org.tmatesoft.svn.core.internal.wc.admin.SVNAdminAreaFactory.createVersionedDirectory(SVNAdminAreaFactory.java:241)
at 
org.tmatesoft.svn.core.internal.wc.SVNWCManager.ensureAdminAreaExists(SVNWCManager.java:428)
at 
org.tmatesoft.svn.core.internal.wc.SVNUpdateEditor.addDir(SVNUpdateEditor.java:762)
at 
org.tmatesoft.svn.core.internal.wc.SVNCancellableEditor.addDir(SVNCancellableEditor.java:84)
at 
org.tmatesoft.svn.core.internal.io.dav.handlers.DAVEditorHandler.startElement(DAVEditorHandler.java:326)
at 
org.tmatesoft.svn.core.internal.io.dav.handlers.BasicDAVHandler.startElement(BasicDAVHandler.java:89)
at 
com.sun.org.apache.xerces.internal.parsers.AbstractSAXPars

Jenkins build became unstable: sling-trunk-1.6 #1956

[Apache Jenkins Server]

See 

Jenkins build became unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing #1956

[Apache Jenkins Server]

See 

[jira] [Commented] (SLING-3144) UserAdmin and GroupAdmin groups are missing on our Oak setup

[Antonio Sanso (JIRA)]

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

Antonio Sanso commented on SLING-3144:
--

thanks [~bdelacretaz] 

bq. In addition, I would suggest having a look at the CreateUserServlet and 
CreateGroupServlet, and make sure they return a 403 forbidden HTTP status and 
log a descriptive message if these groups are missing.

another option is to change the default of the properties that expect those 
groups to empty. IMHO is wrong to count on the presence of them.

WDYT?



> UserAdmin and GroupAdmin groups are missing on our Oak setup
> 
>
> Key: SLING-3144
> URL: https://issues.apache.org/jira/browse/SLING-3144
> Project: Sling
>  Issue Type: Bug
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Attachments: SLING-3144-patch.txt
>
>
> Some of my SLING-2788 integration tests (for example PrivilegesInfoTest) fail 
> as the UserAdmin and GroupAdmin don't initially exist.
> In Jackrabbit those groups are apparently created by 
> UserAccessControlProvider [1] - I'll ask the Oak team how to have the 
> equivalent in Oak.
> As a workaround, creating those groups as follows allows a few more tests to 
> pass - but for the final setup the groups need to be created with specific 
> security-related parameters.
> curl -u admin:admin -F:name=GroupAdmin 
> http://localhost:8080/system/userManager/group.create.html
> curl -u admin:admin -F:name=UserAdmin 
> http://localhost:8080/system/userManager/group.create.html
> [1] 
> http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/core/security/user/UserAccessControlProvider.html



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (SLING-3144) UserAdmin and GroupAdmin groups are missing on our Oak setup

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-3144:


I haven't tested your patch but creating the UserAdmin and GroupAdmin groups 
just for the tests looks good to me.

In addition, I would suggest having a look at the CreateUserServlet and 
CreateGroupServlet, and make sure they return a 403 forbidden HTTP status and 
log a descriptive message if these groups are missing. That can happen in 
distinct issues of course.

> UserAdmin and GroupAdmin groups are missing on our Oak setup
> 
>
> Key: SLING-3144
> URL: https://issues.apache.org/jira/browse/SLING-3144
> Project: Sling
>  Issue Type: Bug
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Attachments: SLING-3144-patch.txt
>
>
> Some of my SLING-2788 integration tests (for example PrivilegesInfoTest) fail 
> as the UserAdmin and GroupAdmin don't initially exist.
> In Jackrabbit those groups are apparently created by 
> UserAccessControlProvider [1] - I'll ask the Oak team how to have the 
> equivalent in Oak.
> As a workaround, creating those groups as follows allows a few more tests to 
> pass - but for the final setup the groups need to be created with specific 
> security-related parameters.
> curl -u admin:admin -F:name=GroupAdmin 
> http://localhost:8080/system/userManager/group.create.html
> curl -u admin:admin -F:name=UserAdmin 
> http://localhost:8080/system/userManager/group.create.html
> [1] 
> http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/core/security/user/UserAccessControlProvider.html



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (SLING-1605) Update documentation

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-1605:


Fix Version/s: (was: Launchpad Base 2.5.2)
   Launchpad Base 2.5.4

> Update documentation
> 
>
> Key: SLING-1605
> URL: https://issues.apache.org/jira/browse/SLING-1605
> Project: Sling
>  Issue Type: Task
>  Components: Launchpad
>Reporter: Carsten Ziegeler
> Fix For: Launchpad Base 2.5.4
>
>
> When releasing version 2.1.0 and 2.2.0 we left some tasks open to be 
> documented:
> SLING-1157
> SLING-922
> SLING-1200
> SLING-1189
> SLING-1443



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (SLING-2757) Support Java 8 as a platform

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-2757:


Fix Version/s: (was: Launchpad Base 2.5.2)
   Launchpad Base 2.5.4

> Support Java 8 as a platform
> 
>
> Key: SLING-2757
> URL: https://issues.apache.org/jira/browse/SLING-2757
> Project: Sling
>  Issue Type: Improvement
>  Components: Launchpad
>Affects Versions: Launchpad Base 2.4.0
>Reporter: Felix Meschberger
> Fix For: Launchpad Base 2.5.4
>
>
> The Sling launchpad currently has Java platform definitions for Java 5, 6, 
> and 7 but is lacking them for Java 8. As a consequence the framework fails to 
> start on Java 8 platforms with exceptions such as:
> 26.11.2012 18:13:10.171 *ERROR* [main] ERROR: Error parsing system bundle 
> export statement: org.osgi.framework; version=1.6, 
> org.osgi.framework.hooks.bundle; version=1.0, 
> org.osgi.framework.hooks.resolver; version=1.0, 
> org.osgi.framework.hooks.service; version=1.1, 
> org.osgi.framework.hooks.weaving; version=1.0, org.osgi.framework.launch; 
> version=1.0, org.osgi.framework.startlevel; version=1.0, 
> org.osgi.framework.wiring; version=1.0, org.osgi.service.packageadmin; 
> version=1.2, org.osgi.service.startlevel; version=1.1, org.osgi.service.url; 
> version=1.0, org.osgi.util.tracker;version="1.5", 
> org.apache.sling.launchpad.api;version=1.1.0,   
> (org.osgi.framework.BundleException: Exported package names cannot be zero 
> length.)
> org.osgi.framework.BundleException: Exported package names cannot be zero 
> length.
>   at 
> org.apache.felix.framework.util.manifestparser.ManifestParser.normalizeExportClauses(ManifestParser.java:729)
>   at 
> org.apache.felix.framework.util.manifestparser.ManifestParser.(ManifestParser.java:191)
>   at 
> org.apache.felix.framework.ExtensionManager.(ExtensionManager.java:221)
>   at org.apache.felix.framework.Felix.(Felix.java:374)
>   at 
> org.apache.sling.launchpad.base.impl.SlingFelix.(SlingFelix.java:45)
>   at 
> org.apache.sling.launchpad.base.impl.Sling.createFramework(Sling.java:343)
>   at org.apache.sling.launchpad.base.impl.Sling.(Sling.java:212)
>   at 
> org.apache.sling.launchpad.base.app.MainDelegate$1.(MainDelegate.java:183)
>   at 
> org.apache.sling.launchpad.base.app.MainDelegate.start(MainDelegate.java:183)
>   at org.apache.sling.launchpad.app.Main.doStart(Main.java:386)
>   at org.apache.sling.launchpad.app.Main.doStart(Main.java:322)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (SLING-3028) Support for progress tracking of jobs and keeping jobs

[Victor Saar (JIRA)]

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

Victor Saar commented on SLING-3028:


I have no deep knowledge of the job processing bundle, but the changes 
generally look good to me. If the progress tracking API is missing anything 
will become apparent when people start using it.

> Support for progress tracking of jobs and keeping jobs
> --
>
> Key: SLING-3028
> URL: https://issues.apache.org/jira/browse/SLING-3028
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Victor Saar
>Assignee: Carsten Ziegeler
>  Labels: jobs
> Fix For: Extensions Event 3.3.0
>
> Attachments: SLING-3028.patch
>
>
> For long-running jobs, it would be useful to have some means to track 
> progress, which can be shown in a console for the user. This should include 
> the following:
> * ETA
> * Completeness value computed from (optional, defaults to 1.0) max and 
> current value (e.g. 42% or 23/100)
> * Log output stream for detailed progress information
> * Failure reason in case job failed
> AFAICS this requires a few changes to the existing implementation:
> * Jobs need additional support for setting properties, e.g. max and current 
> progress value
> * Jobs need to be kept at least for a while after they completed/failed to 
> give access to failure information/log stream



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Build failed in Jenkins: sling-trunk-1.7 #324

[Apache Jenkins Server]

See 

--
[...truncated 309 lines...]
Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT 
/repos/asf/!svn/vcc/default failed
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:379)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:364)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:708)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:335)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1289)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:837)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:507)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274)
at 
org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27)
at 
org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11)
at 
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
at 
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:291)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387)
at 
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157)
... 14 more
Caused by: svn: E175002: REPORT /repos/asf/!svn/vcc/default failed
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97)
... 33 more
Caused by: org.tmatesoft.svn.core.SVNException: svn: E204899: REPORT request 
failed on '/repos/asf/!svn/vcc/default'
svn: E204899: Cannot create new file 
'/home/hudson/jenkins-slave/workspace/sling-trunk-1.7/trunk/samples/espblog/src/main/java/org/apache/sling/samples/espblog/.svn/lock'
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:748)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
... 32 more
Caused by: svn: E204899: REPORT request failed on '/repos/asf/!svn/vcc/default'
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97)
at org.tmatesoft.svn.core.SVNErrorMessage.wrap(SVNErrorMessage.java:407)
... 34 more
Caused by: svn: E204899: Cannot create new file 
'/home/hudson/jenkins-slave/workspace/sling-trunk-1.7/trunk/samples/espblog/src/main/java/org/apache/sling/samples/espblog/.svn/lock'
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:171)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:126)
at 
org.tmatesoft.svn.core.internal.wc.SVNFileUtil.createEmptyFile(SVNFileUtil.java:346)
at 
org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea14.createVersionedDirectory(SVNAdminArea14.java:1553)
at 
org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea16Factory.doCreateVersionedDirectory(SVNAdminArea16Factory.java:30)
at 
org.tmatesoft.svn.core.internal.wc.admin.SVNAdminAreaFactory.createVersionedDirectory(SVNAdminAreaFactory.java:241)
at 
org.tmatesoft.svn.core.internal.wc.SVNWCManager.ensureAdminAreaExists(SVNWCManager.java:428)
at 
org.tmatesoft.svn.core.internal.wc.SVNUpdateEditor.addDir(SVNUpdateEditor.java:762)
at 
org.tmatesoft.svn.core.internal.wc.SVNCancellableEditor.addDir(SVNCancellableEditor.java:84)
at 
org.tmatesoft.svn.core.internal.io.dav.handlers.DAVEditorHandler.startElement(DAVEditorHandler.java:326)
at 
org.tmatesoft.svn.core.internal.io.dav.handlers.BasicDAVHandler.startElement(BasicDAVHandler.java:89)
at 
com.sun.org.apache.xerces.internal.parsers.AbstractSAXPars

[jira] [Updated] (SLING-3143) CreateUserServlet.createUser doesn't work on Oak for UserAdmin group members

[Antonio Sanso (JIRA)]

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

Antonio Sanso updated SLING-3143:
-

Attachment: (was: SLING-3144-patch.txt)

> CreateUserServlet.createUser doesn't work on Oak for UserAdmin group members
> 
>
> Key: SLING-3143
> URL: https://issues.apache.org/jira/browse/SLING-3143
> Project: Sling
>  Issue Type: Bug
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Attachments: SLING-3143-forceAdminSession.patch
>
>
> CreateUserServlet.createUser detects if the current user is a member of the 
> UserAdmin group (group name is configurable), and if that's the case 
> considers the user as admin and uses its session to create a new user.
> This fails on Oak, our launchpad/integration-tests CreateUserTest fails.
> I'll attach a patch that works around the problem by forcing the use of an 
> admin session in this case, but I'm not sure if it's the right thing to do, 
> I'll discuss on the dev list.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Issue Comment Deleted] (SLING-3143) CreateUserServlet.createUser doesn't work on Oak for UserAdmin group members

[Antonio Sanso (JIRA)]

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

Antonio Sanso updated SLING-3143:
-

Comment: was deleted

(was: While I do not like too much this feature of having a special group 
configured via osgi that skips ACLs it seems that is a feature of Sling.

I will attach a patch that would create those groups on demand (only for the 
tests).

[~bdelacretaz] WDYT?)

> CreateUserServlet.createUser doesn't work on Oak for UserAdmin group members
> 
>
> Key: SLING-3143
> URL: https://issues.apache.org/jira/browse/SLING-3143
> Project: Sling
>  Issue Type: Bug
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Attachments: SLING-3143-forceAdminSession.patch
>
>
> CreateUserServlet.createUser detects if the current user is a member of the 
> UserAdmin group (group name is configurable), and if that's the case 
> considers the user as admin and uses its session to create a new user.
> This fails on Oak, our launchpad/integration-tests CreateUserTest fails.
> I'll attach a patch that works around the problem by forcing the use of an 
> admin session in this case, but I'm not sure if it's the right thing to do, 
> I'll discuss on the dev list.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (SLING-3144) UserAdmin and GroupAdmin groups are missing on our Oak setup

[Antonio Sanso (JIRA)]

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

Antonio Sanso updated SLING-3144:
-

Attachment: SLING-3144-patch.txt

> UserAdmin and GroupAdmin groups are missing on our Oak setup
> 
>
> Key: SLING-3144
> URL: https://issues.apache.org/jira/browse/SLING-3144
> Project: Sling
>  Issue Type: Bug
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Attachments: SLING-3144-patch.txt
>
>
> Some of my SLING-2788 integration tests (for example PrivilegesInfoTest) fail 
> as the UserAdmin and GroupAdmin don't initially exist.
> In Jackrabbit those groups are apparently created by 
> UserAccessControlProvider [1] - I'll ask the Oak team how to have the 
> equivalent in Oak.
> As a workaround, creating those groups as follows allows a few more tests to 
> pass - but for the final setup the groups need to be created with specific 
> security-related parameters.
> curl -u admin:admin -F:name=GroupAdmin 
> http://localhost:8080/system/userManager/group.create.html
> curl -u admin:admin -F:name=UserAdmin 
> http://localhost:8080/system/userManager/group.create.html
> [1] 
> http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/core/security/user/UserAccessControlProvider.html



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (SLING-3144) UserAdmin and GroupAdmin groups are missing on our Oak setup

[Antonio Sanso (JIRA)]

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

Antonio Sanso commented on SLING-3144:
--

While I do not like too much this feature of having a special group configured 
via osgi that skips ACLs it seems that is a feature of Sling.

I will attach a patch that would create those groups on demand (only for the 
tests).

Bertrand Delacretaz WDYT?


> UserAdmin and GroupAdmin groups are missing on our Oak setup
> 
>
> Key: SLING-3144
> URL: https://issues.apache.org/jira/browse/SLING-3144
> Project: Sling
>  Issue Type: Bug
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Attachments: SLING-3144-patch.txt
>
>
> Some of my SLING-2788 integration tests (for example PrivilegesInfoTest) fail 
> as the UserAdmin and GroupAdmin don't initially exist.
> In Jackrabbit those groups are apparently created by 
> UserAccessControlProvider [1] - I'll ask the Oak team how to have the 
> equivalent in Oak.
> As a workaround, creating those groups as follows allows a few more tests to 
> pass - but for the final setup the groups need to be created with specific 
> security-related parameters.
> curl -u admin:admin -F:name=GroupAdmin 
> http://localhost:8080/system/userManager/group.create.html
> curl -u admin:admin -F:name=UserAdmin 
> http://localhost:8080/system/userManager/group.create.html
> [1] 
> http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/core/security/user/UserAccessControlProvider.html



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (SLING-3143) CreateUserServlet.createUser doesn't work on Oak for UserAdmin group members

[Antonio Sanso (JIRA)]

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

Antonio Sanso commented on SLING-3143:
--

While I do not like too much this feature of having a special group configured 
via osgi that skips ACLs it seems that is a feature of Sling.

I will attach a patch that would create those groups on demand (only for the 
tests).

[~bdelacretaz] WDYT?

> CreateUserServlet.createUser doesn't work on Oak for UserAdmin group members
> 
>
> Key: SLING-3143
> URL: https://issues.apache.org/jira/browse/SLING-3143
> Project: Sling
>  Issue Type: Bug
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Attachments: SLING-3143-forceAdminSession.patch, SLING-3144-patch.txt
>
>
> CreateUserServlet.createUser detects if the current user is a member of the 
> UserAdmin group (group name is configurable), and if that's the case 
> considers the user as admin and uses its session to create a new user.
> This fails on Oak, our launchpad/integration-tests CreateUserTest fails.
> I'll attach a patch that works around the problem by forcing the use of an 
> admin session in this case, but I'm not sure if it's the right thing to do, 
> I'll discuss on the dev list.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (SLING-3143) CreateUserServlet.createUser doesn't work on Oak for UserAdmin group members

[Antonio Sanso (JIRA)]

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

Antonio Sanso updated SLING-3143:
-

Attachment: SLING-3144-patch.txt

> CreateUserServlet.createUser doesn't work on Oak for UserAdmin group members
> 
>
> Key: SLING-3143
> URL: https://issues.apache.org/jira/browse/SLING-3143
> Project: Sling
>  Issue Type: Bug
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Attachments: SLING-3143-forceAdminSession.patch, SLING-3144-patch.txt
>
>
> CreateUserServlet.createUser detects if the current user is a member of the 
> UserAdmin group (group name is configurable), and if that's the case 
> considers the user as admin and uses its session to create a new user.
> This fails on Oak, our launchpad/integration-tests CreateUserTest fails.
> I'll attach a patch that works around the problem by forcing the use of an 
> admin session in this case, but I'm not sure if it's the right thing to do, 
> I'll discuss on the dev list.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: Stale installer/pom.xml

[Bertrand Delacretaz]

On Wed, Oct 9, 2013 at 12:09 PM, Carsten Ziegeler  wrote:
> ... we once decided to directly references all modules from the root pom
> and get rid of intermediate reactor poms...

ok, I have removed to redundant installer/pom.xml

-Bertrand

[jira] [Commented] (SLING-3156) Add bundles support to Launchpad installer

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-3156:


Ok, I'll have a look - documenting these options at 
http://sling.apache.org/documentation/development/maven-launchpad-plugin.html 
wouldn't hurt.

> Add bundles support to Launchpad installer
> --
>
> Key: SLING-3156
> URL: https://issues.apache.org/jira/browse/SLING-3156
> Project: Sling
>  Issue Type: Improvement
>  Components: Launchpad
>Affects Versions: Launchpad Installer 1.2.0
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>
> The launchpad installer currently supports only configurations, but for 
> SLING-3155 we need to provide runmode-dependent bundles to the OSGi installer.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: Configuration - Well Known Properties Question

[Carsten Ziegeler]

Hi Dan,

yes, I think changing the link to point to the sling.properties section is
the right thing.
For the configuration properties, I think we can completely drop
sling.install and sling.install.bundles.
We could explain org.apache.osgi.bundles - however although they are
supported, Sling provides better mechanisms therefore I think we can leave
this one out.

And right, logging should be org.apache.sling.commons.log.*.

Carsten


2013/10/8 Daniel Klco 

> All,
>
> I am looking into migrating the Configuration page:
> http://sling.staging.apache.org/documentation/configuration.html
>
> The only remaining issue seems to be the links in the Well Known Properties
> section:
>
> http://sling.staging.apache.org/documentation/configuration.html#well-known-properties
>
> The page they link to is just a skeleton, should they link to the
> sling.properties section on the Launchpad page instead?
>
> http://sling.staging.apache.org/documentation/the-sling-engine/the-sling-launchpad.html#slingproperties
>
> Also, I can't seem to find any references to the last three properties:
>
>  - sling.install.bundles
>  - sling.install.
>  - org.apache.sling.osgi.log.*
>
> It seems like the have been changed as follows:
>
> sling.install. -> org.apache.osgi.bundles
> org.apache.sling.osgi.log.* -> org.apache.sling.commons.log.*
>
> Does that sound right?  Or am I missing something?
>
> Thanks,
> Dan
>



-- 
Carsten Ziegeler
cziege...@apache.org

[jira] [Commented] (SLING-3156) Add bundles support to Launchpad installer

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-3156:
-

The startup bundles (OSGi installer, launchpad installer and one or two more) 
need to be specified with:
  in the bundle list - these bundles are the once 
which can't be run mode dependent. All bundles in real start levels including 
the default can use a run mode configuration in the bundle list.

and then the maven launchpad plugin needs to be configured with
install
bundles

Et voila

> Add bundles support to Launchpad installer
> --
>
> Key: SLING-3156
> URL: https://issues.apache.org/jira/browse/SLING-3156
> Project: Sling
>  Issue Type: Improvement
>  Components: Launchpad
>Affects Versions: Launchpad Installer 1.2.0
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>
> The launchpad installer currently supports only configurations, but for 
> SLING-3155 we need to provide runmode-dependent bundles to the OSGi installer.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (SLING-3156) Add bundles support to Launchpad installer

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-3156:
-

Otherwise we would duplicate stuff already in the OSGi installer which is not 
worth the effort

> Add bundles support to Launchpad installer
> --
>
> Key: SLING-3156
> URL: https://issues.apache.org/jira/browse/SLING-3156
> Project: Sling
>  Issue Type: Improvement
>  Components: Launchpad
>Affects Versions: Launchpad Installer 1.2.0
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>
> The launchpad installer currently supports only configurations, but for 
> SLING-3155 we need to provide runmode-dependent bundles to the OSGi installer.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (SLING-3156) Add bundles support to Launchpad installer

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-3156:
-

We don't need to implement this, simply don't use the launchpad installer for 
these bundles and delegate them to the OSGi installer. This is just a tweak of 
configuration (we use this within Adobe) and everything works ootb

> Add bundles support to Launchpad installer
> --
>
> Key: SLING-3156
> URL: https://issues.apache.org/jira/browse/SLING-3156
> Project: Sling
>  Issue Type: Improvement
>  Components: Launchpad
>Affects Versions: Launchpad Installer 1.2.0
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>
> The launchpad installer currently supports only configurations, but for 
> SLING-3155 we need to provide runmode-dependent bundles to the OSGi installer.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (SLING-3157) Launchpad bootstrap: prepare bundles for launchpad installer

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-3157:
-

I think we don't need anything here, look at our Adobe projects where we have 
run mode dependent bundles and configurations and this is using plain Sling 
launchpad/launchpad plugin

> Launchpad bootstrap: prepare bundles for launchpad installer
> 
>
> Key: SLING-3157
> URL: https://issues.apache.org/jira/browse/SLING-3157
> Project: Sling
>  Issue Type: Improvement
>  Components: Launchpad
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> Once SLING-3156 is implemented we'll need to modify the launchpad bootstrap 
> code to copy the runmode-dependent bundles to where the launchpad installer 
> expects to find them.
> Currently, bundles found in the launchpad jar under paths like 
> resources/bundles.foo/5 (for runmode foo and run level 5) are ignored by the 
> bootstrap installer, we might just need to copy those to the right filesystem 
> folder.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Build failed in Jenkins: sling-trunk-1.7 #323

[Apache Jenkins Server]

See 

--
[...truncated 320 lines...]
Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT 
/repos/asf/!svn/vcc/default failed
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:379)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:364)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:708)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:335)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1289)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:837)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:507)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274)
at 
org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27)
at 
org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11)
at 
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
at 
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:291)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387)
at 
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157)
... 14 more
Caused by: svn: E175002: REPORT /repos/asf/!svn/vcc/default failed
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97)
... 33 more
Caused by: org.tmatesoft.svn.core.SVNException: svn: E204899: REPORT request 
failed on '/repos/asf/!svn/vcc/default'
svn: E204899: Cannot create new file 
'/home/hudson/jenkins-slave/workspace/sling-trunk-1.7/trunk/samples/espblog/src/main/java/org/apache/sling/samples/espblog/.svn/lock'
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:748)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
... 32 more
Caused by: svn: E204899: REPORT request failed on '/repos/asf/!svn/vcc/default'
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97)
at org.tmatesoft.svn.core.SVNErrorMessage.wrap(SVNErrorMessage.java:407)
... 34 more
Caused by: svn: E204899: Cannot create new file 
'/home/hudson/jenkins-slave/workspace/sling-trunk-1.7/trunk/samples/espblog/src/main/java/org/apache/sling/samples/espblog/.svn/lock'
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:171)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:126)
at 
org.tmatesoft.svn.core.internal.wc.SVNFileUtil.createEmptyFile(SVNFileUtil.java:346)
at 
org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea14.createVersionedDirectory(SVNAdminArea14.java:1553)
at 
org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea16Factory.doCreateVersionedDirectory(SVNAdminArea16Factory.java:30)
at 
org.tmatesoft.svn.core.internal.wc.admin.SVNAdminAreaFactory.createVersionedDirectory(SVNAdminAreaFactory.java:241)
at 
org.tmatesoft.svn.core.internal.wc.SVNWCManager.ensureAdminAreaExists(SVNWCManager.java:428)
at 
org.tmatesoft.svn.core.internal.wc.SVNUpdateEditor.addDir(SVNUpdateEditor.java:762)
at 
org.tmatesoft.svn.core.internal.wc.SVNCancellableEditor.addDir(SVNCancellableEditor.java:84)
at 
org.tmatesoft.svn.core.internal.io.dav.handlers.DAVEditorHandler.startElement(DAVEditorHandler.java:326)
at 
org.tmatesoft.svn.core.internal.io.dav.handlers.BasicDAVHandler.startElement(BasicDAVHandler.java:89)
at 
com.sun.org.apache.xerces.internal.parsers.AbstractSAXPars

Re: Stale installer/pom.xml

[Carsten Ziegeler]

yepp, we once decided to directly references all modules from the root pom
and get rid of intermediate reactor poms


2013/10/9 Bertrand Delacretaz 

> Hi,
>
> The installer modules are listed in the main pom but there's also an
> installer/pom.xml, can we remove it?
>
> -Bertrand
>



-- 
Carsten Ziegeler
cziege...@apache.org

Re: TopologyConnectorServlet

[Stefan Egli]

On 10/9/13 10:34 AM, "Ian Boston"  wrote:

>On 9 October 2013 09:16, Stefan Egli  wrote:
>> Hi Ian,
>>
>> +1
>>
>> I like the idea of making an API out of this. One thing to remember is
>> that this API would be part of discovery.impl rather than discovery.api
>>-
>> since the discovery.api does not make any assumptions on how
>> instances/clusters discover each other. Nevertheless I think it's a good
>> idea.
>
>Ok, thats probably easier if its Ok for the Discovery Impl to export a
>package.
>
>I forgot 1 thing, there will need to be support for creating the
>aspects of the request that make it trusted, as well as white listing
>it.

I added a suggestion for the API to SLING-3154 - do you see additional
properties (to the plain request object) needed to decide if a request can
be trusted?

>
>
>>
>> Additionally, I wonder if we could also include the possibility of
>> encrypting/decrypting the payload that discovery.impl sends around via
>>the
>> topology connectors? It could be a separate service - eg
>> DiscoveryPayloadHandler - and provide methods to encrypt and
>> decrypt/verify.
>
>That would be a larger patch, but would also work. If its going to
>cover all bases, does it need to be outside the Discovery impl ?

I see it as an optional thing, surely. But was thinking it would be a good
idea to make the API also support that case.

Cheers,
Stefan

>
>I've started a jira for this [1]
>
>Best Regards
>Ian
>
>1 https://issues.apache.org/jira/browse/SLING-3154
>
>
>
>>
>> Cheers,
>> Stefan
>>
>> On 10/8/13 7:40 PM, "Ian Boston"  wrote:
>>
>>>Hi,
>>>The whitelist configuration in this servlet is causing some problems
>>>where the contents of the whitelist is potentially large and changing,
>>>since it requires constant re-configuration.
>>>
>>>Would it be possible to have a API service that is consulted if
>>>present to check if the request is allowed. For those that want to use
>>>the service they would configure the whitelist to reject everything
>>>while the service was not present so avoid startup issues.
>>>
>>>eg
>>>
>>>+@Reference(cardinality=ReferenceCardinality.OPTIONAL_UNARY)
>>>+ private WhiteListProvider   whiteListProvider;
>>>
>>>/** Checks if the provided request's remote server is whitelisted
>>>**/
>>>
>>>private boolean isWhitelisted(final SlingHttpServletRequest
>>>request) {
>>>+  if (whiteListProvider != null) {
>>>+ whiteListProvider.isWhitelisted(request);
>>>+}
>>>if (whitelist.contains(request.getRemoteAddr())) {
>>>
>>>return true;
>>>
>>>} else if (whitelist.contains(request.getRemoteHost())) {
>>>
>>>return true;
>>>
>>>}
>>>
>>>logger.info("isWhitelisted: rejecting " +
>>>request.getRemoteAddr()
>>>
>>>+ ", " + request.getRemoteHost());
>>>
>>>return false;
>>>
>>>}
>>>
>>>
>>>and in the API, presumably discovery api.
>>>
>>>public interface WhiteListProvider {
>>>
>>>private boolean isWhitelisted(HttpServletRequest request);
>>>
>>>}
>>>
>>>
>>>Best Regards
>>>Ian
>>

Jenkins build is back to normal : sling-trunk-1.6 » Apache Sling Launchpad Testing WAR version #1953

[Apache Jenkins Server]

See 

Jenkins build is back to normal : sling-trunk-1.6 #1953

[Apache Jenkins Server]

See 

Jenkins build is back to stable : sling-trunk-1.6 » Apache Sling Resource-Based Discovery Service #1953

[Apache Jenkins Server]

See 

Jenkins build is back to normal : sling-trunk-1.7 #322

[Apache Jenkins Server]

See 

Jenkins build is back to stable : sling-trunk-1.7 » Apache Sling SLF4J Implementation (Logback) #322

[Apache Jenkins Server]

See 

[jira] [Created] (SLING-3157) Launchpad bootstrap: prepare bundles for launchpad installer

[Bertrand Delacretaz (JIRA)]

Bertrand Delacretaz created SLING-3157:
--

 Summary: Launchpad bootstrap: prepare bundles for launchpad 
installer
 Key: SLING-3157
 URL: https://issues.apache.org/jira/browse/SLING-3157
 Project: Sling
  Issue Type: Improvement
  Components: Launchpad
Reporter: Bertrand Delacretaz
Assignee: Bertrand Delacretaz
Priority: Minor


Once SLING-3156 is implemented we'll need to modify the launchpad bootstrap 
code to copy the runmode-dependent bundles to where the launchpad installer 
expects to find them.

Currently, bundles found in the launchpad jar under paths like 
resources/bundles.foo/5 (for runmode foo and run level 5) are ignored by the 
bootstrap installer, we might just need to copy those to the right filesystem 
folder.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (SLING-3156) Add bundles support to Launchpad installer

[Bertrand Delacretaz (JIRA)]

Bertrand Delacretaz created SLING-3156:
--

 Summary: Add bundles support to Launchpad installer
 Key: SLING-3156
 URL: https://issues.apache.org/jira/browse/SLING-3156
 Project: Sling
  Issue Type: Improvement
  Components: Launchpad
Affects Versions: Launchpad Installer 1.2.0
Reporter: Bertrand Delacretaz
Assignee: Bertrand Delacretaz


The launchpad installer currently supports only configurations, but for 
SLING-3155 we need to provide runmode-dependent bundles to the OSGi installer.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (SLING-3155) Switch launchpad between Jackrabbit and Oak based on run modes

[Bertrand Delacretaz (JIRA)]

Bertrand Delacretaz created SLING-3155:
--

 Summary: Switch launchpad between Jackrabbit and Oak based on run 
modes
 Key: SLING-3155
 URL: https://issues.apache.org/jira/browse/SLING-3155
 Project: Sling
  Issue Type: Improvement
  Components: Launchpad
Reporter: Bertrand Delacretaz
Assignee: Bertrand Delacretaz


We need this to run our integration tests on both Jackrabbit and Oak.

Using -Dsling.run.modes=jackrabbit (or oak) on the first startup of the 
launchpad runnable jar will switch.

These run modes need to be set to be mutually exclusive and considered only on 
the first startup, we don't support switching later. We'll need to support 
upgrading a Jackrabbit repository to Oak but that's a different issue.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (SLING-1803) add coverage reporting of integration tests

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-1803:


For now I have added a new jacoco-report profile to the Sling parent pom, 
http://svn.apache.org/r1530538

With this, a build that's run with -Pjacoco-report and includes tests produces 
a test coverage report at target/site/jacoco/index.html

> add coverage reporting of integration tests
> ---
>
> Key: SLING-1803
> URL: https://issues.apache.org/jira/browse/SLING-1803
> Project: Sling
>  Issue Type: New Feature
>  Components: Launchpad
>Reporter: Justin Edelson
>Assignee: Bertrand Delacretaz
> Attachments: integration-deploys-jacoco-exec.patch, jacoco-pom.patch, 
> SLING-1803-1053340.patch
>
>
> I've tried both emma and clover. Looks like emma is the right choice as it is 
> a little more flexible in terms of breaking apart the instrumentation from 
> the test execution.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (SLING-3154) Add Topology Message Verification to the Discovery service.

[Stefan Egli (JIRA)]

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

Stefan Egli commented on SLING-3154:


I think we might be able to cover both aspects (the whitelist, and the 
encrypt/decrypt) with one API - basically provide one hook to 'pack' a payload 
for posting and one for 'unpacking' (and thus verifying) upon reception. Eg the 
API could be along the following lines:

public interface DiscoveryPayloadHandler {

public RequestEntity pack(String json);

public String unpack(SlingHttpServletRequest request) throws 
RejectException;

}

Whereas pack() would be used in the TopologyConnectorClient before posting the 
request, and unpack() would be used in the TopologyConnectorServlet when 
handling the PUT/DELETE requests. Throwing of the RejectException would imply 
ignoring/rejecting the request/announcement.

pack/unpack could be doing encrypt/decrypt/verify - but they could also do 
things like gizp for example.

> Add Topology Message Verification to the Discovery service.
> ---
>
> Key: SLING-3154
> URL: https://issues.apache.org/jira/browse/SLING-3154
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Affects Versions: Discovery Impl 1.0.0
>Reporter: Ian Boston
>Assignee: Ian Boston
> Fix For: Discovery Impl 1.0.2
>
>
> The discovery service provides support for whitelisting sources of topology 
> information, but in a cluster where the topology this creates a 
> re-configuration load of order M*(n*(n-1)) where n is the number of nodes in 
> the topology and M is the number of changes. That load rises rapidly as the 
> number of changes and/or nodes increases. 
> To address this there are 2 proposals.
> 1. To provide an SPI exported from the Discovery Impl bundle that allows 
> implementors to implement whitelisting based on the request. This will need 
> to support creating the request and validating the request.
> 2. Embed functionality within the Discovery Impl bundle that supports 
> validation and encryption of topology requests.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Comment Edited] (SLING-3154) Add Topology Message Verification to the Discovery service.

[Stefan Egli (JIRA)]

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

Stefan Egli edited comment on SLING-3154 at 10/9/13 9:03 AM:
-

I think we might be able to cover both aspects (the whitelist, and the 
encrypt/decrypt) with one API - basically provide one hook to 'pack' a payload 
for posting and one for 'unpacking' (and thus verifying) upon reception. Eg the 
API could be along the following lines:
{code:java}
public interface DiscoveryPayloadHandler {

public RequestEntity pack(String json);

public String unpack(SlingHttpServletRequest request) throws 
RejectException;

}
{code}
Whereas pack() would be used in the TopologyConnectorClient before posting the 
request, and unpack() would be used in the TopologyConnectorServlet when 
handling the PUT/DELETE requests. Throwing of the RejectException would imply 
ignoring/rejecting the request/announcement.

pack/unpack could be doing encrypt/decrypt/verify - but they could also do 
things like gizp for example.


was (Author: egli):
I think we might be able to cover both aspects (the whitelist, and the 
encrypt/decrypt) with one API - basically provide one hook to 'pack' a payload 
for posting and one for 'unpacking' (and thus verifying) upon reception. Eg the 
API could be along the following lines:

public interface DiscoveryPayloadHandler {

public RequestEntity pack(String json);

public String unpack(SlingHttpServletRequest request) throws 
RejectException;

}

Whereas pack() would be used in the TopologyConnectorClient before posting the 
request, and unpack() would be used in the TopologyConnectorServlet when 
handling the PUT/DELETE requests. Throwing of the RejectException would imply 
ignoring/rejecting the request/announcement.

pack/unpack could be doing encrypt/decrypt/verify - but they could also do 
things like gizp for example.

> Add Topology Message Verification to the Discovery service.
> ---
>
> Key: SLING-3154
> URL: https://issues.apache.org/jira/browse/SLING-3154
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Affects Versions: Discovery Impl 1.0.0
>Reporter: Ian Boston
>Assignee: Ian Boston
> Fix For: Discovery Impl 1.0.2
>
>
> The discovery service provides support for whitelisting sources of topology 
> information, but in a cluster where the topology this creates a 
> re-configuration load of order M*(n*(n-1)) where n is the number of nodes in 
> the topology and M is the number of changes. That load rises rapidly as the 
> number of changes and/or nodes increases. 
> To address this there are 2 proposals.
> 1. To provide an SPI exported from the Discovery Impl bundle that allows 
> implementors to implement whitelisting based on the request. This will need 
> to support creating the request and validating the request.
> 2. Embed functionality within the Discovery Impl bundle that supports 
> validation and encryption of topology requests.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: TopologyConnectorServlet

[Ian Boston]

On 9 October 2013 09:16, Stefan Egli  wrote:
> Hi Ian,
>
> +1
>
> I like the idea of making an API out of this. One thing to remember is
> that this API would be part of discovery.impl rather than discovery.api -
> since the discovery.api does not make any assumptions on how
> instances/clusters discover each other. Nevertheless I think it's a good
> idea.

Ok, thats probably easier if its Ok for the Discovery Impl to export a package.

I forgot 1 thing, there will need to be support for creating the
aspects of the request that make it trusted, as well as white listing
it.


>
> Additionally, I wonder if we could also include the possibility of
> encrypting/decrypting the payload that discovery.impl sends around via the
> topology connectors? It could be a separate service - eg
> DiscoveryPayloadHandler - and provide methods to encrypt and
> decrypt/verify.

That would be a larger patch, but would also work. If its going to
cover all bases, does it need to be outside the Discovery impl ?

I've started a jira for this [1]

Best Regards
Ian

1 https://issues.apache.org/jira/browse/SLING-3154



>
> Cheers,
> Stefan
>
> On 10/8/13 7:40 PM, "Ian Boston"  wrote:
>
>>Hi,
>>The whitelist configuration in this servlet is causing some problems
>>where the contents of the whitelist is potentially large and changing,
>>since it requires constant re-configuration.
>>
>>Would it be possible to have a API service that is consulted if
>>present to check if the request is allowed. For those that want to use
>>the service they would configure the whitelist to reject everything
>>while the service was not present so avoid startup issues.
>>
>>eg
>>
>>+@Reference(cardinality=ReferenceCardinality.OPTIONAL_UNARY)
>>+ private WhiteListProvider   whiteListProvider;
>>
>>/** Checks if the provided request's remote server is whitelisted **/
>>
>>private boolean isWhitelisted(final SlingHttpServletRequest request) {
>>+  if (whiteListProvider != null) {
>>+ whiteListProvider.isWhitelisted(request);
>>+}
>>if (whitelist.contains(request.getRemoteAddr())) {
>>
>>return true;
>>
>>} else if (whitelist.contains(request.getRemoteHost())) {
>>
>>return true;
>>
>>}
>>
>>logger.info("isWhitelisted: rejecting " + request.getRemoteAddr()
>>
>>+ ", " + request.getRemoteHost());
>>
>>return false;
>>
>>}
>>
>>
>>and in the API, presumably discovery api.
>>
>>public interface WhiteListProvider {
>>
>>private boolean isWhitelisted(HttpServletRequest request);
>>
>>}
>>
>>
>>Best Regards
>>Ian
>

[jira] [Created] (SLING-3154) Add Topology Message Verification to the Discovery service.

[Ian Boston (JIRA)]

Ian Boston created SLING-3154:
-

 Summary: Add Topology Message Verification to the Discovery 
service.
 Key: SLING-3154
 URL: https://issues.apache.org/jira/browse/SLING-3154
 Project: Sling
  Issue Type: Improvement
  Components: General
Affects Versions: Discovery Impl 1.0.0
Reporter: Ian Boston
Assignee: Ian Boston
 Fix For: Discovery Impl 1.0.2


The discovery service provides support for whitelisting sources of topology 
information, but in a cluster where the topology this creates a 
re-configuration load of order M*(n*(n-1)) where n is the number of nodes in 
the topology and M is the number of changes. That load rises rapidly as the 
number of changes and/or nodes increases. 

To address this there are 2 proposals.

1. To provide an SPI exported from the Discovery Impl bundle that allows 
implementors to implement whitelisting based on the request. This will need to 
support creating the request and validating the request.

2. Embed functionality within the Discovery Impl bundle that supports 
validation and encryption of topology requests.





--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: TopologyConnectorServlet

[Stefan Egli]

Hi Ian,

+1

I like the idea of making an API out of this. One thing to remember is
that this API would be part of discovery.impl rather than discovery.api -
since the discovery.api does not make any assumptions on how
instances/clusters discover each other. Nevertheless I think it's a good
idea.

Additionally, I wonder if we could also include the possibility of
encrypting/decrypting the payload that discovery.impl sends around via the
topology connectors? It could be a separate service - eg
DiscoveryPayloadHandler - and provide methods to encrypt and
decrypt/verify.

Cheers,
Stefan

On 10/8/13 7:40 PM, "Ian Boston"  wrote:

>Hi,
>The whitelist configuration in this servlet is causing some problems
>where the contents of the whitelist is potentially large and changing,
>since it requires constant re-configuration.
>
>Would it be possible to have a API service that is consulted if
>present to check if the request is allowed. For those that want to use
>the service they would configure the whitelist to reject everything
>while the service was not present so avoid startup issues.
>
>eg
>
>+@Reference(cardinality=ReferenceCardinality.OPTIONAL_UNARY)
>+ private WhiteListProvider   whiteListProvider;
>
>/** Checks if the provided request's remote server is whitelisted **/
>
>private boolean isWhitelisted(final SlingHttpServletRequest request) {
>+  if (whiteListProvider != null) {
>+ whiteListProvider.isWhitelisted(request);
>+}
>if (whitelist.contains(request.getRemoteAddr())) {
>
>return true;
>
>} else if (whitelist.contains(request.getRemoteHost())) {
>
>return true;
>
>}
>
>logger.info("isWhitelisted: rejecting " + request.getRemoteAddr()
>
>+ ", " + request.getRemoteHost());
>
>return false;
>
>}
>
>
>and in the API, presumably discovery api.
>
>public interface WhiteListProvider {
>
>private boolean isWhitelisted(HttpServletRequest request);
>
>}
>
>
>Best Regards
>Ian

Stale installer/pom.xml

[Bertrand Delacretaz]

Hi,

The installer modules are listed in the main pom but there's also an
installer/pom.xml, can we remove it?

-Bertrand