[jira] [Commented] (SLING-3278) Provide a HealthCheckExecutor service
[ https://issues.apache.org/jira/browse/SLING-3278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13852731#comment-13852731 ] Georg Henzler commented on SLING-3278: -- 1) maybe we should rather go run(String fullyQualifiedClassname) then - although getting the service is easy it's also easy to get it wrong. And it's just a waste to get the service if you don't need to (the executor does not get the service if there is a cache hit, there is async results or a future is running already) 2) I agree we should get of the method setHealthCheckDescriptor(), but adding as constructor element is not an easy option (the health check itself is constructing it, but it is set by the executor later). If we add it as a constructor parameter we need a clone constructor Result(resultFromCheckItself, hcDescriptor, finishedDate, elapsedTime). Or we put the class result behind an implementation class (that would be a nicer option IMHO), the problem with that is that new Result(...) is used directly in the checks and is part of the current API = the clone constructor is probably still the better solution 3) The descriptor contains currently the hc name and the tags - this meta information is useful in the UI (it is shown in the web console). Before my patch the service reference was used directly in the web console (using a lot more code, e.g. dealing with the fact that the OSGi array props do appear as simple string if only one element is contained). Now IMHO it is cleanly separated and the HC meta information is available to the UI (without being tied to the OSGi API, also see your first point ;-)). Another option would be to copy name and tags as plain properties to the Result, but IMHO it is cleaner and more extensible to leave the constant meta data (not changing for multiple hc executions) in a separate class (also it is a really useful key class for the executor, if we got rid of it in the API we should at least leave it in the impl.executor package) Provide a HealthCheckExecutor service - Key: SLING-3278 URL: https://issues.apache.org/jira/browse/SLING-3278 Project: Sling Issue Type: New Feature Components: Health Check Reporter: Georg Henzler Assignee: Georg Henzler Attachments: SLING-3278-bertrand.patch, SLING-3278-hc.core-HealthCheckExecutorService-2013-12-19.patch, SLING-3278-hc.webconsole-2013-12-19.patch, hc-it.patch Goals: * Be able to get an overall (aggregated) result as quickly as possible (ideally 2sec) * Whenever possible, return most current results (e.g. for a memory check) * Provide a declarative way for async checks (async checks should be the exception though) Approach * Run checks in parallel * Make sure long running (or even stuck) checks are timed out * If a health check must run asynchronously (because its execution time cannot be optimized), it should be enough to just specify a service property (e.g. hc.async). See also http://apache-sling.73963.n3.nabble.com/Health-Check-Improvements-td4029330.html#a4029402 http://apache-sling.73963.n3.nabble.com/Health-checks-execution-service-td4028477.html -- This message was sent by Atlassian JIRA (v6.1.4#6159)
Long startup time with many vanityPath or alias
hi *, in SLING-3290 [0] I have started to write some performance test regarding long startup time with many vanityPath or alias. As you might see from the attached graph the startup time increases considerably with the number of vanityPath. The same should applies to aliases (I am writing the test case). The reason behind this is comment and should be IMHO the usage of a query that updates the global map entry. In fact the issue doesn't occur only at startup but as well every time a vanityPath/alias is updated. IMHO would be nice to try to improve this situation. WDYT? regards antonio [0] https://issues.apache.org/jira/browse/SLING-3290
[jira] [Created] (SLING-3295) Add a scheduled replication rule
Tommaso Teofili created SLING-3295: -- Summary: Add a scheduled replication rule Key: SLING-3295 URL: https://issues.apache.org/jira/browse/SLING-3295 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Tommaso Teofili To schedule replication agents actions on certain paths every X seconds it'd be good to have a dedicated replication rule, using Sling Scheduler -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (SLING-3295) Add a scheduled replication rule
[ https://issues.apache.org/jira/browse/SLING-3295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3295: --- Attachment: SLING-3295.patch Add a scheduled replication rule Key: SLING-3295 URL: https://issues.apache.org/jira/browse/SLING-3295 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Tommaso Teofili Attachments: SLING-3295.patch To schedule replication agents actions on certain paths every X seconds it'd be good to have a dedicated replication rule, using Sling Scheduler -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[RT] Fluent API for HealthCheckExecutor
Hi,
I thought a bit more about the SLING-3278 HealthCheckExecutor service,
and a fluent interface might be useful:
interface HealthCheckExecutor {
/** Select all HealthChecks for execution */
HealthCheckContext all();
/** Select a single HealthCheck for execution */
HealthCheckContext for(HealthCheck hc);
/** Select HealthChecks by tag for execution */
HealthCheckContext forTags(String ...tags);
}
/** Context holds execution options and triggers the actual execution */
interface HealthCheckContext {
void withTimeout(int timeout, TimeUnits units);
void clearCache();
AggregatedResult getResult();
ListResult getAllResults();
}
Which allows for writing things like
executor.all().getAllResults();
executor.for(hc).getResult();
executor
.forTags(foo, -bar)
.withTimeout(5, TimeUnit.SECONDS)
.getResult();
// Clear cache before execution
executor.forTags(security).clearCache().getAllResults();
// Clear all cached Results
executor.all().clearCache();
AggregatedResult extends Result with a ListResult getResults()
method. Its status is the highest of the aggregated statuses, and its
log is the concatenation of all individual logs.
WDYT?
-Bertrand
[jira] [Commented] (SLING-3278) Provide a HealthCheckExecutor service
[ https://issues.apache.org/jira/browse/SLING-3278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13852761#comment-13852761 ] Bertrand Delacretaz commented on SLING-3278: I'm also for having an executor method that takes a single HealthCheck - getting the service is not expensive, I don't think that's a problem, and that's consistent with how we generally do things in Sling. bq. We cannot use a created date in the Result constructor because the instance of the result is created by the implementing class... It's created when the check is done executing, as the Result is immutable there's no other way. So I think storing the creation timestamp at that point is fine. If a health check starts at T, runs for 2 minutes and has a time to live of 1 minute, you want to kill it at T+3, not T+1. So IMO we should set the Result creation time in its constructor, have a method to set the time to live and an isExpired method that becomes true at T+3 in my example. In the meantime I've thought about a fluent API that looks better for the executor, started a thread on our dev list to discuss that ([RT] Fluent API for HealthCheckExecutor). That would have little impact to the core of your patch, but provide a more flexible API, including per-call execution timeouts and the ability to clear some or all cached results at will. Provide a HealthCheckExecutor service - Key: SLING-3278 URL: https://issues.apache.org/jira/browse/SLING-3278 Project: Sling Issue Type: New Feature Components: Health Check Reporter: Georg Henzler Assignee: Georg Henzler Attachments: SLING-3278-bertrand.patch, SLING-3278-hc.core-HealthCheckExecutorService-2013-12-19.patch, SLING-3278-hc.webconsole-2013-12-19.patch, hc-it.patch Goals: * Be able to get an overall (aggregated) result as quickly as possible (ideally 2sec) * Whenever possible, return most current results (e.g. for a memory check) * Provide a declarative way for async checks (async checks should be the exception though) Approach * Run checks in parallel * Make sure long running (or even stuck) checks are timed out * If a health check must run asynchronously (because its execution time cannot be optimized), it should be enough to just specify a service property (e.g. hc.async). See also http://apache-sling.73963.n3.nabble.com/Health-Check-Improvements-td4029330.html#a4029402 http://apache-sling.73963.n3.nabble.com/Health-checks-execution-service-td4028477.html -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Comment Edited] (SLING-3278) Provide a HealthCheckExecutor service
[ https://issues.apache.org/jira/browse/SLING-3278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13852762#comment-13852762 ] Carsten Ziegeler edited comment on SLING-3278 at 12/19/13 9:33 AM: --- 1) The class name is implementation detail, no one knows it - I can live with it if we go with health check name, so if I want to execute a hc via the executor, it has to have a name or a tag. Deal? 2) The Executor could return an ExecutionResult (or maybe there is a better name), containing the additional information and as a field the result 3) Ok, I'm fine with having this descriptor as long as it is a simple data object not containing any complex objects like a ServiceReference. The idea behind all of this is to make this serializable and be able to serialize it to a remote machine. As long as these are data objects, everything is fine, but a ServiceReference can never be transferred was (Author: cziegeler): 1) The class name is implementation detail, no one knows it - I can leave it we go with health check name, so if I want to execute a hc via the executor, it has to have a name or a tag. Deal? 2) The Executor could return an ExecutionResult (or maybe there is a better name), containing the additional information and as a field the result 3) Ok, I'm fine with having this descriptor as long as it is a simple data object not containing any complex objects like a ServiceReference. The idea behind all of this is to make this serializable and be able to serialize it to a remote machine. As long as these are data objects, everything is fine, but a ServiceReference can never be transferred Provide a HealthCheckExecutor service - Key: SLING-3278 URL: https://issues.apache.org/jira/browse/SLING-3278 Project: Sling Issue Type: New Feature Components: Health Check Reporter: Georg Henzler Assignee: Georg Henzler Attachments: SLING-3278-bertrand.patch, SLING-3278-hc.core-HealthCheckExecutorService-2013-12-19.patch, SLING-3278-hc.webconsole-2013-12-19.patch, hc-it.patch Goals: * Be able to get an overall (aggregated) result as quickly as possible (ideally 2sec) * Whenever possible, return most current results (e.g. for a memory check) * Provide a declarative way for async checks (async checks should be the exception though) Approach * Run checks in parallel * Make sure long running (or even stuck) checks are timed out * If a health check must run asynchronously (because its execution time cannot be optimized), it should be enough to just specify a service property (e.g. hc.async). See also http://apache-sling.73963.n3.nabble.com/Health-Check-Improvements-td4029330.html#a4029402 http://apache-sling.73963.n3.nabble.com/Health-checks-execution-service-td4028477.html -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (SLING-3278) Provide a HealthCheckExecutor service
[ https://issues.apache.org/jira/browse/SLING-3278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13852762#comment-13852762 ] Carsten Ziegeler commented on SLING-3278: - 1) The class name is implementation detail, no one knows it - I can leave it we go with health check name, so if I want to execute a hc via the executor, it has to have a name or a tag. Deal? 2) The Executor could return an ExecutionResult (or maybe there is a better name), containing the additional information and as a field the result 3) Ok, I'm fine with having this descriptor as long as it is a simple data object not containing any complex objects like a ServiceReference. The idea behind all of this is to make this serializable and be able to serialize it to a remote machine. As long as these are data objects, everything is fine, but a ServiceReference can never be transferred Provide a HealthCheckExecutor service - Key: SLING-3278 URL: https://issues.apache.org/jira/browse/SLING-3278 Project: Sling Issue Type: New Feature Components: Health Check Reporter: Georg Henzler Assignee: Georg Henzler Attachments: SLING-3278-bertrand.patch, SLING-3278-hc.core-HealthCheckExecutorService-2013-12-19.patch, SLING-3278-hc.webconsole-2013-12-19.patch, hc-it.patch Goals: * Be able to get an overall (aggregated) result as quickly as possible (ideally 2sec) * Whenever possible, return most current results (e.g. for a memory check) * Provide a declarative way for async checks (async checks should be the exception though) Approach * Run checks in parallel * Make sure long running (or even stuck) checks are timed out * If a health check must run asynchronously (because its execution time cannot be optimized), it should be enough to just specify a service property (e.g. hc.async). See also http://apache-sling.73963.n3.nabble.com/Health-Check-Improvements-td4029330.html#a4029402 http://apache-sling.73963.n3.nabble.com/Health-checks-execution-service-td4028477.html -- This message was sent by Atlassian JIRA (v6.1.4#6159)
Re: [RT] New Feature Flags API / Impl
Hi Amit
thanks for the feedback - yes, good point with active vs available. I'll
change that.
Yes, as the implementation manages the contexts, it first calls isEnabled
on the providers to know which features are enabled and then only calls the
other methos like hideResource if the feature is really enabled. This
avoids double checking. I'll make some updates to the javadocs
Thanks
Carsten
2013/12/19 Amit.. Gupta. amitg...@adobe.com
Hi Carsten,
In FeatureManager
String[] getFeatureNames();
Javadoc says it returns all active features. Active might give an
impression of this only returning enabled features, but rather it returns
all available features. Changing the javadoc will also align with
FeatureManager.isAvailable.
And, I could not understand how context is passed on in
FeatureManager.hideResource(final String featureName, final Resource
resource)
Is it the caller's responsibility to first check isEnabled(featureName,
context), before calling hideResource?
Thanks,
-Amit
-Original Message-
From: Carsten Ziegeler [mailto:cziege...@apache.org]
Sent: 19 December 2013 10:33
To: dev@sling.apache.org
Subject: [RT] New Feature Flags API / Impl
Hi,
I've started with a new approach to implement the feature flags - the
focus is on the API, which means what features do our feature flags have
and how can they report it. (The implementation should be functional but I
haven't checked it yet).
I went back and forth with different approaches based on Bertrands
prototype and all the discussions and I think this approach is the most
promising one:
The central service for client code is the Features service:
public interface Features {
String[] getFeatureNames();
boolean isAvailable(String featureName);
ClientContext createClientContext(ResourceResolver resolver);
ClientContext createClientContext(SlingHttpServletRequest request);
ClientContext getCurrentClientContext();
}
This can be used to find out which features are available and to create a
client context - the context is either based on a request or on a resource
resolver.
The client context in turn can be used to find out whether a feature is
enabled:
public interface ClientContext {
boolean isEnabled(String featureName);
CollectionString getEnabledFeatures(); }
So a script can use this, to do things differently etc.
In addition the Features services provides the current client context
which is automatically available for a request.
Now, somehow we need an API to define which feature is available and what
it does - I came up with an extended version of the FeatureProvider (and
I'm not so sure about this one):
public interface FeatureProvider {
String [] getFeatureNames();
boolean isEnabled(String featureName, ProviderContext context);
MapString, String getResourceTypeMapping(String featureName);
boolean hideResource(String featureName, Resource resource); } It's
similar to the Bertrand's version, except that it takes a ProviderContext
(which allows access to the request and resource resolver) and has two
additional methods control the two most wanted features: hiding resources
and changing of resource types.
We could then implement this provider reading OSGi configurations or
whatever to define features.
All constructive feedback welcome - and as I said, let's first define the
API
Everything can be found at:
http://svn.apache.org/repos/asf/sling/whiteboard/feature-flags/
Regards
Carsten
--
Carsten Ziegeler
cziege...@apache.org
--
Carsten Ziegeler
cziege...@apache.org
[jira] [Created] (SLING-3296) Occasional NPE in EstablishedClusterView
Bertrand Delacretaz created SLING-3296: -- Summary: Occasional NPE in EstablishedClusterView Key: SLING-3296 URL: https://issues.apache.org/jira/browse/SLING-3296 Project: Sling Issue Type: Bug Components: Extensions Reporter: Bertrand Delacretaz Priority: Minor Happened in http://ci.apache.org/builders/sling-trunk-oak/builds/52: testAdditionalInstance(org.apache.sling.discovery.impl.cluster.ClusterTest) Time elapsed: 4.253 sec ERROR! java.lang.NullPointerException at org.apache.sling.discovery.impl.common.resource.EstablishedClusterView.init(EstablishedClusterView.java:55) at org.apache.sling.discovery.impl.cluster.ClusterViewServiceImpl.getClusterView(ClusterViewServiceImpl.java:141) at org.apache.sling.discovery.impl.DiscoveryServiceImpl.getTopology(DiscoveryServiceImpl.java:406) at org.apache.sling.discovery.impl.DiscoveryServiceImpl.handlePotentialTopologyChange(DiscoveryServiceImpl.java:452) at org.apache.sling.discovery.impl.DiscoveryServiceImpl.updateProperties(DiscoveryServiceImpl.java:427) at org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.issueHeartbeat(HeartbeatHandler.java:250) at org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.run(HeartbeatHandler.java:207) at org.apache.sling.discovery.impl.setup.Instance.runHeartbeatOnce(Instance.java:340) at org.apache.sling.discovery.impl.cluster.ClusterTest.testAdditionalInstance(ClusterTest.java:322) -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (SLING-3296) Occasional NPE in EstablishedClusterView
[ https://issues.apache.org/jira/browse/SLING-3296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SLING-3296: --- Affects Version/s: Discovery Impl 1.0.2 Occasional NPE in EstablishedClusterView Key: SLING-3296 URL: https://issues.apache.org/jira/browse/SLING-3296 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Discovery Impl 1.0.2 Reporter: Bertrand Delacretaz Priority: Minor Happened in http://ci.apache.org/builders/sling-trunk-oak/builds/52: testAdditionalInstance(org.apache.sling.discovery.impl.cluster.ClusterTest) Time elapsed: 4.253 sec ERROR! java.lang.NullPointerException at org.apache.sling.discovery.impl.common.resource.EstablishedClusterView.init(EstablishedClusterView.java:55) at org.apache.sling.discovery.impl.cluster.ClusterViewServiceImpl.getClusterView(ClusterViewServiceImpl.java:141) at org.apache.sling.discovery.impl.DiscoveryServiceImpl.getTopology(DiscoveryServiceImpl.java:406) at org.apache.sling.discovery.impl.DiscoveryServiceImpl.handlePotentialTopologyChange(DiscoveryServiceImpl.java:452) at org.apache.sling.discovery.impl.DiscoveryServiceImpl.updateProperties(DiscoveryServiceImpl.java:427) at org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.issueHeartbeat(HeartbeatHandler.java:250) at org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.run(HeartbeatHandler.java:207) at org.apache.sling.discovery.impl.setup.Instance.runHeartbeatOnce(Instance.java:340) at org.apache.sling.discovery.impl.cluster.ClusterTest.testAdditionalInstance(ClusterTest.java:322) -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (SLING-3292) Web Hooks for Resource Observation
[ https://issues.apache.org/jira/browse/SLING-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13852905#comment-13852905 ] Felix Meschberger commented on SLING-3292: -- This sounds interesting. Yet, we have to see how this may scale to not block the server with event processing. Maybe we can buffer event transmission for a certain amount of time, e.g. 0.5-3 seconds and then send the events as JSON arrays of JSON arrarys of events. Needs to be discussed whether we base on JCR Events or Sling Resource Events. Reading the issue description I habe the impression to consider Sling Resource Events. Web Hooks for Resource Observation -- Key: SLING-3292 URL: https://issues.apache.org/jira/browse/SLING-3292 Project: Sling Issue Type: New Feature Components: Extensions Reporter: Lars Trieloff Priority: Minor I have an application that is storing resources for multiple other web applications and makes them available through the Sling REST API. Each of the consuming web applications has implemented their own caching and polling strategy for the resources made available by my Sling web application. In order to reduce latency when resources get updated in my Sling web application, and to reduce the need for polling resources on the side of my consuming web application, I would like to support Web Hooks (https://webhooks.pbworks.com/w/page/13385124/FrontPage - a pattern also supported by applications such as GitHub https://help.github.com/articles/post-receive-hooks or Evernote http://dev.evernote.com/doc/articles/polling_notification.php), so that client applications can register callbacks when one of the resources in my web application changes. The events to be observed should be: * resource added * resource moved * resource deleted * resource updated An observing application should be able to specify: * a pattern of resource paths it is interested in * a collection of resource types it is interested in * a collection of events it is interested in * a callback URL that should receive POST requests when a change matching the pattern above has been made The subsequent POST request should contain following information * timestamp of the change * URL of the changed resource * event type of the change * user initiating the change Furthermore, observing applications should be able to * create a new listener using a POST request * GET the list of listeners already registered * POST to update or delete an existing listener h5. Error Handling In case the registered callback URL is not available, Sling should retry the notification POST request, with increasing time between retries. After a maximum number of retries, the listener should be blacklisted, so that no further retries are being made h5. Configuration * maximum number of retries * enforce HTTPS (for production use) * authentication for outgoing requests -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (SLING-3292) Web Hooks for Resource Observation
[ https://issues.apache.org/jira/browse/SLING-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13852955#comment-13852955 ] Lars Trieloff commented on SLING-3292: -- It looks like buffering is a common approach, for instance SendGrid buffers for 1 second or until the buffer reaches a size of 1 MB: http://sendgrid.com/docs/API_Reference/Webhooks/event.html I would prefer Sling Resource Events, as most of Sling's API operates on this abstraction, but to my knowledge JCR is the most common resource provider supporting observation. Web Hooks for Resource Observation -- Key: SLING-3292 URL: https://issues.apache.org/jira/browse/SLING-3292 Project: Sling Issue Type: New Feature Components: Extensions Reporter: Lars Trieloff Priority: Minor I have an application that is storing resources for multiple other web applications and makes them available through the Sling REST API. Each of the consuming web applications has implemented their own caching and polling strategy for the resources made available by my Sling web application. In order to reduce latency when resources get updated in my Sling web application, and to reduce the need for polling resources on the side of my consuming web application, I would like to support Web Hooks (https://webhooks.pbworks.com/w/page/13385124/FrontPage - a pattern also supported by applications such as GitHub https://help.github.com/articles/post-receive-hooks or Evernote http://dev.evernote.com/doc/articles/polling_notification.php), so that client applications can register callbacks when one of the resources in my web application changes. The events to be observed should be: * resource added * resource moved * resource deleted * resource updated An observing application should be able to specify: * a pattern of resource paths it is interested in * a collection of resource types it is interested in * a collection of events it is interested in * a callback URL that should receive POST requests when a change matching the pattern above has been made The subsequent POST request should contain following information * timestamp of the change * URL of the changed resource * event type of the change * user initiating the change Furthermore, observing applications should be able to * create a new listener using a POST request * GET the list of listeners already registered * POST to update or delete an existing listener h5. Error Handling In case the registered callback URL is not available, Sling should retry the notification POST request, with increasing time between retries. After a maximum number of retries, the listener should be blacklisted, so that no further retries are being made h5. Configuration * maximum number of retries * enforce HTTPS (for production use) * authentication for outgoing requests -- This message was sent by Atlassian JIRA (v6.1.4#6159)
Re: [RT] Fluent API for HealthCheckExecutor
Hi,
although in general I like fluent APIs, in this case IMHO there is not
really a point in creating one. The HealthCheckExecutor is only to be
used by JMX and the web console (and maybe at some point by some
servlet), but not as part of a normal implementation project. However, I
think projects will implement their own health checks, but rarely have
the need to execute them in a custom fashion if JMX and the web console
are configurable in a flexible way. It is really like Servlets: You
implement the interface and make them known to the container, but you
don't ever run them yourself from java (as the container does this for
you).
-Georg
Am 19.12.2013 11:21, schrieb Bertrand Delacretaz:
Hi,
I thought a bit more about the SLING-3278 HealthCheckExecutor
service,
and a fluent interface might be useful:
interface HealthCheckExecutor {
/** Select all HealthChecks for execution */
HealthCheckContext all();
/** Select a single HealthCheck for execution */
HealthCheckContext for(HealthCheck hc);
/** Select HealthChecks by tag for execution */
HealthCheckContext forTags(String ...tags);
}
/** Context holds execution options and triggers the actual execution
*/
interface HealthCheckContext {
void withTimeout(int timeout, TimeUnits units);
void clearCache();
AggregatedResult getResult();
ListResult getAllResults();
}
Which allows for writing things like
executor.all().getAllResults();
executor.for(hc).getResult();
executor
.forTags(foo, -bar)
.withTimeout(5, TimeUnit.SECONDS)
.getResult();
// Clear cache before execution
executor.forTags(security).clearCache().getAllResults();
// Clear all cached Results
executor.all().clearCache();
AggregatedResult extends Result with a ListResult getResults()
method. Its status is the highest of the aggregated statuses, and its
log is the concatenation of all individual logs.
WDYT?
-Bertrand
[jira] [Commented] (SLING-3278) Provide a HealthCheckExecutor service
[ https://issues.apache.org/jira/browse/SLING-3278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13852998#comment-13852998 ] Georg Henzler commented on SLING-3278: -- Re Fluent API as well as The class name is implementation detail, no one knows it: I think we have a disconnect in how we think the health check executor could/should be used. I think implementation projects really only want to be able to add checks and run them via web console or JMX, they would never want to execute the checks in a custom fashion other than configuring timeouts or restricting it to certain tags (also see mailing list post). @Carsten / 1): I think you need the run(hc-class) mainly for the JMX module: Don't you have access to the classname via the property component.name there? The problem with the name is that it may contain spaces and therefore is not really a nice id for using it as a parameter? 2) The ExecutionResult is a good idea - that way all timing data can go there. Also, Execution Result should be an interface and ExecutionResultImpl can be hidden in the impl.executor package - that way ExecutionResultImpl does not have to be immutable and the timing data can be collected correctly (also solving Bertrands concerns). 3) If we create the interface ExecutionResult, we can hide the existence of the HealthCheckDescriptor and move it to impl.executor. The field serviceReference can be marked transient and is therefore be taken out from Serialization (if that really ever is needed, I think probably not) Provide a HealthCheckExecutor service - Key: SLING-3278 URL: https://issues.apache.org/jira/browse/SLING-3278 Project: Sling Issue Type: New Feature Components: Health Check Reporter: Georg Henzler Assignee: Georg Henzler Attachments: SLING-3278-bertrand.patch, SLING-3278-hc.core-HealthCheckExecutorService-2013-12-19.patch, SLING-3278-hc.webconsole-2013-12-19.patch, hc-it.patch Goals: * Be able to get an overall (aggregated) result as quickly as possible (ideally 2sec) * Whenever possible, return most current results (e.g. for a memory check) * Provide a declarative way for async checks (async checks should be the exception though) Approach * Run checks in parallel * Make sure long running (or even stuck) checks are timed out * If a health check must run asynchronously (because its execution time cannot be optimized), it should be enough to just specify a service property (e.g. hc.async). See also http://apache-sling.73963.n3.nabble.com/Health-Check-Improvements-td4029330.html#a4029402 http://apache-sling.73963.n3.nabble.com/Health-checks-execution-service-td4028477.html -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (SLING-3281) Expose more information on the replication queues
[ https://issues.apache.org/jira/browse/SLING-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3281: --- Attachment: SLING-3281.5.patch Expose more information on the replication queues - Key: SLING-3281 URL: https://issues.apache.org/jira/browse/SLING-3281 Project: Sling Issue Type: Task Components: Extensions Reporter: Tommaso Teofili Attachments: SLING-3281.2.patch, SLING-3281.3.patch, SLING-3281.4.patch, SLING-3281.5.patch, SLING-3281.patch It'd be useful to have more information on: 1. the items contained in a replication queue being still be able to process one item at a time. 2. how to remove a specific item This will ease the monitoring of what's in the replication queues and also to use queues as the buffer to pull items from a remote instance. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[RFC] YAMF - Yet Another Model Factory
Hi, I've published a page to the wiki about a concept I've been working on to consolidate the various appproaches I have seen in the wild to model object creation. I'm calling this YAMF for now, although ideally we'll just call it Sling Models :) Without repeating the whole contents of the wiki page, at a high level, this is a purely annotation driven approach supporting both classes and interfaces. Your model class simply needs to declare from which other classes it can be adapted: @Model(adaptables=Resource.class) And then annotate the fields (for classes) and methods (for interfaces) which need injection: @Inject private String propertyName; You can inject properties, OSGi services, request attributes, and entries from SlingBindings. New injector types can be created through an SPI. Additional annotations are supported for special cases: @Optional - mark a field/method as optional. @Filter - provide a filter (i.e. for OSGi services) @Named - specify a name (other than the default field/method name) to use for the inejction lookup. More detail can be found here: https://cwiki.apache.org/confluence/display/SLING/YAMF+-+Yet+Another+Model+Factory The working code is up in my whiteboard: https://svn.apache.org/repos/asf/sling/whiteboard/justin/yamf/ Look forward to your feedback. Regards, Justin
Re: [RFC] YAMF - Yet Another Model Factory
HI Justin, thank a lot for that. I am assuming a lot of developers were waiting for just that. Could you extend the wiki page with an example on how the model bean should then be used from within the view (i.e. the JSP) and also some words about the scope of one instance? One very good addition to the annotations would probably be a default value in case there is nothing reasonable to be injected (very useful for resource values which are not yet set). Thanks, Konrad Am 19.12.2013 um 18:07 schrieb Justin Edelson jus...@justinedelson.com: Hi, I've published a page to the wiki about a concept I've been working on to consolidate the various appproaches I have seen in the wild to model object creation. I'm calling this YAMF for now, although ideally we'll just call it Sling Models :) Without repeating the whole contents of the wiki page, at a high level, this is a purely annotation driven approach supporting both classes and interfaces. Your model class simply needs to declare from which other classes it can be adapted: @Model(adaptables=Resource.class) And then annotate the fields (for classes) and methods (for interfaces) which need injection: @Inject private String propertyName; You can inject properties, OSGi services, request attributes, and entries from SlingBindings. New injector types can be created through an SPI. Additional annotations are supported for special cases: @Optional - mark a field/method as optional. @Filter - provide a filter (i.e. for OSGi services) @Named - specify a name (other than the default field/method name) to use for the inejction lookup. More detail can be found here: https://cwiki.apache.org/confluence/display/SLING/YAMF+-+Yet+Another+Model+Factory The working code is up in my whiteboard: https://svn.apache.org/repos/asf/sling/whiteboard/justin/yamf/ Look forward to your feedback. Regards, Justin
[jira] [Created] (SLING-3297) Sling-based mail archive server sample contribution
Igor Bogomolov created SLING-3297: - Summary: Sling-based mail archive server sample contribution Key: SLING-3297 URL: https://issues.apache.org/jira/browse/SLING-3297 Project: Sling Issue Type: Wish Reporter: Igor Bogomolov Priority: Trivial During my internship at Adobe I have developed a Mail archive server based on Sling. I think it is good example of Sling-based application and would like to contribute it to Sling project. Just submitted an ICLA. I will attach code to this issue. Project initial repository is at https://github.com/ibogomolov/mail-archive-server. It includes documentation and issues. Let me know if there is anything else I should do. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
Re: [RFC] YAMF - Yet Another Model Factory
Hi Konrad, Thanks for the feedback. From a client perspective (i.e. a JSP), they are just using the adapter framework. The fact that that adaption is annotation driven isn't important to the client (or visible for that matter). I'll try to make that more obvious. Defaults are a good idea. Justin On Thu, Dec 19, 2013 at 12:21 PM, Konrad Windszus konra...@gmx.de wrote: HI Justin, thank a lot for that. I am assuming a lot of developers were waiting for just that. Could you extend the wiki page with an example on how the model bean should then be used from within the view (i.e. the JSP) and also some words about the scope of one instance? One very good addition to the annotations would probably be a default value in case there is nothing reasonable to be injected (very useful for resource values which are not yet set). Thanks, Konrad Am 19.12.2013 um 18:07 schrieb Justin Edelson jus...@justinedelson.com: Hi, I've published a page to the wiki about a concept I've been working on to consolidate the various appproaches I have seen in the wild to model object creation. I'm calling this YAMF for now, although ideally we'll just call it Sling Models :) Without repeating the whole contents of the wiki page, at a high level, this is a purely annotation driven approach supporting both classes and interfaces. Your model class simply needs to declare from which other classes it can be adapted: @Model(adaptables=Resource.class) And then annotate the fields (for classes) and methods (for interfaces) which need injection: @Inject private String propertyName; You can inject properties, OSGi services, request attributes, and entries from SlingBindings. New injector types can be created through an SPI. Additional annotations are supported for special cases: @Optional - mark a field/method as optional. @Filter - provide a filter (i.e. for OSGi services) @Named - specify a name (other than the default field/method name) to use for the inejction lookup. More detail can be found here: https://cwiki.apache.org/confluence/display/SLING/YAMF+-+Yet+Another+Model+Factory The working code is up in my whiteboard: https://svn.apache.org/repos/asf/sling/whiteboard/justin/yamf/ Look forward to your feedback. Regards, Justin
Re: [RT] Fluent API for HealthCheckExecutor
On Thursday, December 19, 2013, Georg Henzler wrote: ...The HealthCheckExecutor is only to be used by JMX and the web console (and maybe at some point by some servlet), but not as part of a normal implementation project... That's a very limiting view. If you have spellchecking services for example, it might be a good idea to expose their status to your content authors...something like executor.forTags(spellchecker).getResult() -Bertrand
Re: [RFC] YAMF - Yet Another Model Factory
Justin, This seems like a really nice addition. I was working on something similar using Java's Dynamic Proxy to allow injection from the repository. The model is slightly different where instead of annotating member variables, you annotate methods on an interface. http://svn.apache.org/repos/asf/sling/whiteboard/dklco/dynamic-proxy/ Overall, I'd actually say I like the approach you've defined. A couple thoughts though: - Would it make sense to separate the property/service injection annotations to make it more clear what's being injected? - How about adding support for the naming as variables in the Inject annotation instead of a separate annotation? This would also go for some of the other annotations. I think from a developer's perspective it makes more sense to configure an annotation than have to look up a bunch of different unconnected annotations, - Do the filters just work on service injection? - So this one confuses me a little: @Inject @Named(log) private Logger logger; Is the @Named being used for the page / request attributes? How can one tell from where the injectable object will be loaded? Would there be any value/reason to being able to specify? Very cool though over all! -Dan On Thu, Dec 19, 2013 at 12:21 PM, Konrad Windszus konra...@gmx.de wrote: HI Justin, thank a lot for that. I am assuming a lot of developers were waiting for just that. Could you extend the wiki page with an example on how the model bean should then be used from within the view (i.e. the JSP) and also some words about the scope of one instance? One very good addition to the annotations would probably be a default value in case there is nothing reasonable to be injected (very useful for resource values which are not yet set). Thanks, Konrad Am 19.12.2013 um 18:07 schrieb Justin Edelson jus...@justinedelson.com: Hi, I've published a page to the wiki about a concept I've been working on to consolidate the various appproaches I have seen in the wild to model object creation. I'm calling this YAMF for now, although ideally we'll just call it Sling Models :) Without repeating the whole contents of the wiki page, at a high level, this is a purely annotation driven approach supporting both classes and interfaces. Your model class simply needs to declare from which other classes it can be adapted: @Model(adaptables=Resource.class) And then annotate the fields (for classes) and methods (for interfaces) which need injection: @Inject private String propertyName; You can inject properties, OSGi services, request attributes, and entries from SlingBindings. New injector types can be created through an SPI. Additional annotations are supported for special cases: @Optional - mark a field/method as optional. @Filter - provide a filter (i.e. for OSGi services) @Named - specify a name (other than the default field/method name) to use for the inejction lookup. More detail can be found here: https://cwiki.apache.org/confluence/display/SLING/YAMF+-+Yet+Another+Model+Factory The working code is up in my whiteboard: https://svn.apache.org/repos/asf/sling/whiteboard/justin/yamf/ Look forward to your feedback. Regards, Justin
[jira] [Updated] (SLING-3297) Sling-based mail archive server sample contribution
[ https://issues.apache.org/jira/browse/SLING-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Bogomolov updated SLING-3297: -- Attachment: sling-mail-archive-server.zip Sling-based mail archive server sample contribution --- Key: SLING-3297 URL: https://issues.apache.org/jira/browse/SLING-3297 Project: Sling Issue Type: Wish Reporter: Igor Bogomolov Priority: Trivial Attachments: sling-mail-archive-server.zip During my internship at Adobe I have developed a Mail archive server based on Sling. I think it is good example of Sling-based application and would like to contribute it to Sling project. Just submitted an ICLA. I will attach code to this issue. Project initial repository is at https://github.com/ibogomolov/mail-archive-server. It includes documentation and issues. Let me know if there is anything else I should do. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
Re: [RFC] YAMF - Yet Another Model Factory
Hi Dan, On Thu, Dec 19, 2013 at 12:37 PM, Daniel Klco dk...@apache.org wrote: Justin, This seems like a really nice addition. I was working on something similar using Java's Dynamic Proxy to allow injection from the repository. The model is slightly different where instead of annotating member variables, you annotate methods on an interface. http://svn.apache.org/repos/asf/sling/whiteboard/dklco/dynamic-proxy/ Yes - proxy based injection (of methods) works too. Most of the tests are written with classes, but there is one or two with interfaces. The SPI handles both cases. Overall, I'd actually say I like the approach you've defined. A couple thoughts though: - Would it make sense to separate the property/service injection annotations to make it more clear what's being injected? I don't think so - as a model developer, I shouldn't necessarily care where my injections are coming from, just that they are being injected. - How about adding support for the naming as variables in the Inject annotation instead of a separate annotation? This would also go for some of the other annotations. I think from a developer's perspective it makes more sense to configure an annotation than have to look up a bunch of different unconnected annotations, As I wrote, one of the design goals is to use standard annotations. @Inject and @Named are common annotations defined in the JDK. - Do the filters just work on service injection? Correct, although there's no reason a different Injector couldn't use them. - So this one confuses me a little: @Inject @Named(log) private Logger logger; Is the @Named being used for the page / request attributes? Yes - in this case, log is the name of the SlingBindings attribute. How can one tell from where the injectable object will be loaded? You can't :) Would there be any value/reason to being able to specify? I don't think so, but I'm curious for others opinions. As someone who builds a model class, why should it matter? I just say I want a String instance named 'firstProperty' and it magically appears. Too magical? Justin Very cool though over all! -Dan On Thu, Dec 19, 2013 at 12:21 PM, Konrad Windszus konra...@gmx.de wrote: HI Justin, thank a lot for that. I am assuming a lot of developers were waiting for just that. Could you extend the wiki page with an example on how the model bean should then be used from within the view (i.e. the JSP) and also some words about the scope of one instance? One very good addition to the annotations would probably be a default value in case there is nothing reasonable to be injected (very useful for resource values which are not yet set). Thanks, Konrad Am 19.12.2013 um 18:07 schrieb Justin Edelson jus...@justinedelson.com: Hi, I've published a page to the wiki about a concept I've been working on to consolidate the various appproaches I have seen in the wild to model object creation. I'm calling this YAMF for now, although ideally we'll just call it Sling Models :) Without repeating the whole contents of the wiki page, at a high level, this is a purely annotation driven approach supporting both classes and interfaces. Your model class simply needs to declare from which other classes it can be adapted: @Model(adaptables=Resource.class) And then annotate the fields (for classes) and methods (for interfaces) which need injection: @Inject private String propertyName; You can inject properties, OSGi services, request attributes, and entries from SlingBindings. New injector types can be created through an SPI. Additional annotations are supported for special cases: @Optional - mark a field/method as optional. @Filter - provide a filter (i.e. for OSGi services) @Named - specify a name (other than the default field/method name) to use for the inejction lookup. More detail can be found here: https://cwiki.apache.org/confluence/display/SLING/YAMF+-+Yet+Another+Model+Factory The working code is up in my whiteboard: https://svn.apache.org/repos/asf/sling/whiteboard/justin/yamf/ Look forward to your feedback. Regards, Justin
Re: [RFC] YAMF - Yet Another Model Factory
Hi Konrad, Defaults have been implemented. Check the wiki. Regards, Justin On Thu, Dec 19, 2013 at 12:21 PM, Konrad Windszus konra...@gmx.de wrote: HI Justin, thank a lot for that. I am assuming a lot of developers were waiting for just that. Could you extend the wiki page with an example on how the model bean should then be used from within the view (i.e. the JSP) and also some words about the scope of one instance? One very good addition to the annotations would probably be a default value in case there is nothing reasonable to be injected (very useful for resource values which are not yet set). Thanks, Konrad Am 19.12.2013 um 18:07 schrieb Justin Edelson jus...@justinedelson.com: Hi, I've published a page to the wiki about a concept I've been working on to consolidate the various appproaches I have seen in the wild to model object creation. I'm calling this YAMF for now, although ideally we'll just call it Sling Models :) Without repeating the whole contents of the wiki page, at a high level, this is a purely annotation driven approach supporting both classes and interfaces. Your model class simply needs to declare from which other classes it can be adapted: @Model(adaptables=Resource.class) And then annotate the fields (for classes) and methods (for interfaces) which need injection: @Inject private String propertyName; You can inject properties, OSGi services, request attributes, and entries from SlingBindings. New injector types can be created through an SPI. Additional annotations are supported for special cases: @Optional - mark a field/method as optional. @Filter - provide a filter (i.e. for OSGi services) @Named - specify a name (other than the default field/method name) to use for the inejction lookup. More detail can be found here: https://cwiki.apache.org/confluence/display/SLING/YAMF+-+Yet+Another+Model+Factory The working code is up in my whiteboard: https://svn.apache.org/repos/asf/sling/whiteboard/justin/yamf/ Look forward to your feedback. Regards, Justin
Re: [i18n] jcr resource bundle provider
On 18.12.2013, at 21:44, Tobias Bocanegra tri...@apache.org wrote: I don't really like the automatic upgrade, since we really don't know how to differentiate use of mix:language/sling:message in compact subtrees vs the sparse case. It might be to expensive to traverse the mix:language nodes for each bundle activation. We don't need a traversal - just that one query we currently already do and which we want to replace because it is potentially a bit slow. And it's only on the _first_ bundle activation, afterwards the has been migrated flag is set. The nested mix:language scenario should be easy to handle by just looking at the paths: + mix:language ... + mix:language ... + sling:Message If you get nested paths, you only look at the longer one. The only awful scenario could be this: + mix:language ... + sling:Message + mix:language ... + sling:Message But it doesn't make any sense, so I can't imagine anyone using it. I would rather have a semi automatic fallback as described before: 0. read the operation-mode osgi config property (default: auto). 1. if mode==auto: 1.1 search (query) for all sling:Dictionary nodes 1.2. if non found, assume old content and set mode=legacy That only allows one version at the same time. If we update the ootb dictionaries in our application to use the sling:dictionary node types, but customers have their own dictionaries, these would not work anymore after upgrading. Cheers, Alex
Re: [RT] Fluent API for HealthCheckExecutor
You have a good example here - I'm not sure though if you would really call the health check before a spell check or if it is not better to have good exception handling for the actual call of the spell checker if things go wrong. What if the health check returns green and 20ms later the service is away... the exception handling for the actual call of the the spell check still has to be in place for this case! (making the call to the health check beforehand really obsolete) But let's say we want to use a health check to show a result for a tag to the author: You still can do so with the API of the current patch of SLING-3278: Result result = executor.runForTags(spellchecker); The fluent API would allow to specify timeouts or clearing the cache per execution. I think it's better to configure TTLs and HC timeouts once (either per check or a default globally). For instance, if you have the spellcheck service health check: Does it really make sense to use a different timeout for a message to the author than for the web console used by a admin guy? The timeout is mainly influenced by typical response times of the service, not by whom is looking at the result. -Georg Am 19.12.2013 19:24, schrieb Bertrand Delacretaz: On Thursday, December 19, 2013, Georg Henzler wrote: ...The HealthCheckExecutor is only to be used by JMX and the web console (and maybe at some point by some servlet), but not as part of a normal implementation project... That's a very limiting view. If you have spellchecking services for example, it might be a good idea to expose their status to your content authors...something like executor.forTags(spellchecker).getResult() -Bertrand
Re: [RFC] YAMF - Yet Another Model Factory
Hi Justin, thanks a lot. I would like to see a section in the wiki where required injections are described in detail. I guess in case for injected Sling values which are not there the instantiation fails (i.e. adaptTo will return null). What happens in case a default value is specified? In my regard the annotations Optional and Default should not be combined. Regards, Konrad Am 19.12.2013 um 22:33 schrieb Justin Edelson jus...@justinedelson.com: Hi Konrad, Defaults have been implemented. Check the wiki. Regards, Justin On Thu, Dec 19, 2013 at 12:21 PM, Konrad Windszus konra...@gmx.de wrote: HI Justin, thank a lot for that. I am assuming a lot of developers were waiting for just that. Could you extend the wiki page with an example on how the model bean should then be used from within the view (i.e. the JSP) and also some words about the scope of one instance? One very good addition to the annotations would probably be a default value in case there is nothing reasonable to be injected (very useful for resource values which are not yet set). Thanks, Konrad Am 19.12.2013 um 18:07 schrieb Justin Edelson jus...@justinedelson.com: Hi, I've published a page to the wiki about a concept I've been working on to consolidate the various appproaches I have seen in the wild to model object creation. I'm calling this YAMF for now, although ideally we'll just call it Sling Models :) Without repeating the whole contents of the wiki page, at a high level, this is a purely annotation driven approach supporting both classes and interfaces. Your model class simply needs to declare from which other classes it can be adapted: @Model(adaptables=Resource.class) And then annotate the fields (for classes) and methods (for interfaces) which need injection: @Inject private String propertyName; You can inject properties, OSGi services, request attributes, and entries from SlingBindings. New injector types can be created through an SPI. Additional annotations are supported for special cases: @Optional - mark a field/method as optional. @Filter - provide a filter (i.e. for OSGi services) @Named - specify a name (other than the default field/method name) to use for the inejction lookup. More detail can be found here: https://cwiki.apache.org/confluence/display/SLING/YAMF+-+Yet+Another+Model+Factory The working code is up in my whiteboard: https://svn.apache.org/repos/asf/sling/whiteboard/justin/yamf/ Look forward to your feedback. Regards, Justin
