[jira] [Created] (SLING-4805) ResourceResolver should extend Closable interface.
Michał Chudy created SLING-4805:
---
Summary: ResourceResolver should extend Closable interface.
Key: SLING-4805
URL: https://issues.apache.org/jira/browse/SLING-4805
Project: Sling
Issue Type: Improvement
Components: API, JCR
Affects Versions: API 2.9.0, JCR Resource 2.5.0
Reporter: Michał Chudy
While creating {{ResourceResolver}}, we have to remember to close it and code
looks like that:
{code}
ResourceResolver resourceResolver = null;
try {
resourceResolver =
resourceResolverFactory.getServiceResourceResolver(null);
} catch (LoginException e) {
LOGGER.error(Error during getting instance of ResourceResolver class,
e);
} finally {
if (resourceResolver != null) {
resourceResolver.close();
}
}
{code}
While making {{ResourceResolver}} additionally extend {{Closable}} (or
{{AutoClosable}}) interface, we could use try-with-resources Java 7 feature and
our code would be more concise, elegant, readable.
{code}
try (ResourceResolver resolver = factory.getServiceResourceResolver(null)) {
//do sth
}
{code}
(Please notice that {{Closable}} is still part of Java 6 API)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4804) Semicolon parameters are not passed to the resource resolver
[
https://issues.apache.org/jira/browse/SLING-4804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomek Rękawek updated SLING-4804:
-
Attachment: SLING-4804.patch
The attached patch adds the semicolon parameter back to the path in the
{{RequestData#initResource()}}. It also adds an integration test that checks
the semicolon parameters support using the {{;v=1.1}} to retrieve a historic
resource.
Semicolon parameters are not passed to the resource resolver
Key: SLING-4804
URL: https://issues.apache.org/jira/browse/SLING-4804
Project: Sling
Issue Type: Bug
Components: Engine
Affects Versions: Engine 2.4.2
Reporter: Tomek Rękawek
Assignee: Tomek Rękawek
Priority: Minor
Fix For: Engine 2.4.4
Attachments: SLING-4804.patch
SLING-848 provided a way to pass semicolon-separated parameters to the
resource provider. However, such parameters are removed from the
{{HttpServletRequest#getPathInfo()}}, which is used in the
{{RequestData#initResource()}} method to resolve the resource from the URI.
As a result, resource resolver and resource provider don't see the semicolon
parameters and can't use them.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14584478#comment-14584478 ] Tomek Rękawek commented on SLING-848: - I created a simple http test in the SLING-4804. It helped me discovering a bug, also fixed in the SLING-4804. The patch modifies the Sling Engine - it would be great if you can take a look on it. Support getting versioned resources by using uri path parameters Key: SLING-848 URL: https://issues.apache.org/jira/browse/SLING-848 Project: Sling Issue Type: New Feature Components: API, JCR, ResourceResolver Affects Versions: JCR Resource 2.0.2 Reporter: Carsten Ziegeler Assignee: Tomek Rękawek Fix For: JCR Resource 2.5.0, API 2.9.0, Resource Resolver 1.2.0 Attachments: SLING-848-metadata.patch Getting versioned content should be support thorough uri path parameters, like /something/hello;v=1.1 For jcr based resources the value of the version should either point to a version name or label. In order to not change our existing apis, we introduce a new utility method which removes all uri path parameters and returns a map of these. Every resource provider could use this utility method and then decide to act on these parameters. If a requested version does not exists, a 404 is returned. If the requested node does not directly point to a versionable node, the algorithm checks the parent hierarchy until a versionable node is found, and tries to get the version of this node and then goes down the path again. If the versionable node does not have the requested version or the child, a 404 is returned. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4805) ResourceResolver should extend Closable interface.
[
https://issues.apache.org/jira/browse/SLING-4805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-4805:
Affects Version/s: (was: API 2.9.0)
ResourceResolver should extend Closable interface.
--
Key: SLING-4805
URL: https://issues.apache.org/jira/browse/SLING-4805
Project: Sling
Issue Type: Improvement
Components: API, JCR
Affects Versions: JCR Resource 2.5.0
Reporter: Michał Chudy
While creating {{ResourceResolver}}, we have to remember to close it and code
looks like that:
{code}
ResourceResolver resourceResolver = null;
try {
resourceResolver =
resourceResolverFactory.getServiceResourceResolver(null);
} catch (LoginException e) {
LOGGER.error(Error during getting instance of ResourceResolver class,
e);
} finally {
if (resourceResolver != null) {
resourceResolver.close();
}
}
{code}
While making {{ResourceResolver}} additionally extend {{Closable}} (or
{{AutoClosable}}) interface, we could use try-with-resources Java 7 feature
and our code would be more concise, elegant, readable.
{code}
try (ResourceResolver resolver = factory.getServiceResourceResolver(null)) {
//do sth
}
{code}
(Please notice that {{Closable}} is still part of Java 6 API)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4805) ResourceResolver should extend Closable interface.
[
https://issues.apache.org/jira/browse/SLING-4805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-4805:
Affects Version/s: (was: JCR Resource 2.5.0)
API 2.9.0
ResourceResolver should extend Closable interface.
--
Key: SLING-4805
URL: https://issues.apache.org/jira/browse/SLING-4805
Project: Sling
Issue Type: Improvement
Components: API
Affects Versions: API 2.9.0
Reporter: Michał Chudy
Fix For: API 2.10.0
While creating {{ResourceResolver}}, we have to remember to close it and code
looks like that:
{code}
ResourceResolver resourceResolver = null;
try {
resourceResolver =
resourceResolverFactory.getServiceResourceResolver(null);
} catch (LoginException e) {
LOGGER.error(Error during getting instance of ResourceResolver class,
e);
} finally {
if (resourceResolver != null) {
resourceResolver.close();
}
}
{code}
While making {{ResourceResolver}} additionally extend {{Closable}} (or
{{AutoClosable}}) interface, we could use try-with-resources Java 7 feature
and our code would be more concise, elegant, readable.
{code}
try (ResourceResolver resolver = factory.getServiceResourceResolver(null)) {
//do sth
}
{code}
(Please notice that {{Closable}} is still part of Java 6 API)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-4805) ResourceResolver should extend Closable interface.
[
https://issues.apache.org/jira/browse/SLING-4805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved SLING-4805.
-
Resolution: Fixed
The resource resolver interface now extends Closeable
ResourceResolver should extend Closable interface.
--
Key: SLING-4805
URL: https://issues.apache.org/jira/browse/SLING-4805
Project: Sling
Issue Type: Improvement
Components: API
Affects Versions: API 2.9.0
Reporter: Michał Chudy
Assignee: Carsten Ziegeler
Fix For: API 2.10.0
While creating {{ResourceResolver}}, we have to remember to close it and code
looks like that:
{code}
ResourceResolver resourceResolver = null;
try {
resourceResolver =
resourceResolverFactory.getServiceResourceResolver(null);
} catch (LoginException e) {
LOGGER.error(Error during getting instance of ResourceResolver class,
e);
} finally {
if (resourceResolver != null) {
resourceResolver.close();
}
}
{code}
While making {{ResourceResolver}} additionally extend {{Closable}} (or
{{AutoClosable}}) interface, we could use try-with-resources Java 7 feature
and our code would be more concise, elegant, readable.
{code}
try (ResourceResolver resolver = factory.getServiceResourceResolver(null)) {
//do sth
}
{code}
(Please notice that {{Closable}} is still part of Java 6 API)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (SLING-4691) throws information is missing on Resource, ResourceUtil, and ResourceResolver.
[ https://issues.apache.org/jira/browse/SLING-4691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-4691: --- Assignee: Carsten Ziegeler throws information is missing on Resource, ResourceUtil, and ResourceResolver. -- Key: SLING-4691 URL: https://issues.apache.org/jira/browse/SLING-4691 Project: Sling Issue Type: Improvement Components: API Affects Versions: API 2.9.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: API 2.10.0 The methods in the Resource interface are mssing the potential exceptions that might be thrown in the javadocs. For example listChildren forwards to the resource resolver which might throw IllegalStateException or SlingException Maybe other interfaces/classes are affected as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4691) throws information is missing on Resource, ResourceUtil, and ResourceResolver.
[ https://issues.apache.org/jira/browse/SLING-4691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-4691: Summary: throws information is missing on Resource, ResourceUtil, and ResourceResolver. (was: throws information is missing on Resource) throws information is missing on Resource, ResourceUtil, and ResourceResolver. -- Key: SLING-4691 URL: https://issues.apache.org/jira/browse/SLING-4691 Project: Sling Issue Type: Improvement Components: API Affects Versions: API 2.9.0 Reporter: Carsten Ziegeler Fix For: API 2.10.0 The methods in the Resource interface are mssing the potential exceptions that might be thrown in the javadocs. For example listChildren forwards to the resource resolver which might throw IllegalStateException or SlingException Maybe other interfaces/classes are affected as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4790) Removal of artifacts from inherited model is not possible
[ https://issues.apache.org/jira/browse/SLING-4790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-4790. --- Removal of artifacts from inherited model is not possible - Key: SLING-4790 URL: https://issues.apache.org/jira/browse/SLING-4790 Project: Sling Issue Type: Bug Components: Maven Plugins and Archetypes, Tooling Affects Versions: Sling Provisioning Model 1.1.0, Slingstart Maven Plugin 1.1.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Sling Provisioning Model 1.2.0, Slingstart Maven Plugin 1.2.0 Currently an artifact (or configuration) can't be removed from an inherited model as the local model is read and merged first which removes the :remove run mode from the read model. Afterwards. the dependencies are read and the local model is merged into this. However as the :remove run mode is already gone, it's not possible to remove anything from inherited models -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4768) Sort entries alphabetical in written model
[ https://issues.apache.org/jira/browse/SLING-4768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-4768. --- Sort entries alphabetical in written model -- Key: SLING-4768 URL: https://issues.apache.org/jira/browse/SLING-4768 Project: Sling Issue Type: Improvement Components: Tooling Affects Versions: Sling Provisioning Model 1.1.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Sling Provisioning Model 1.2.0 We should sort the entries (artifacts, configurations) alphabetical in a written model. This makes diffing them much easier -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4793) Support new format from Apache Felix config admin
[ https://issues.apache.org/jira/browse/SLING-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-4793. --- Support new format from Apache Felix config admin - Key: SLING-4793 URL: https://issues.apache.org/jira/browse/SLING-4793 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: Installer Core 3.6.4 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Installer Core 3.6.6 With version 1.8.6 of the config admin implementation, an improved format for multi values has been introduced. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4786) Attributes and configuration format are wronlgy written out
[ https://issues.apache.org/jira/browse/SLING-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-4786. --- Attributes and configuration format are wronlgy written out --- Key: SLING-4786 URL: https://issues.apache.org/jira/browse/SLING-4786 Project: Sling Issue Type: Bug Components: Tooling Affects Versions: Sling Provisioning Model 1.1.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Sling Provisioning Model 1.2.0 When a configuration is written out, the format information is wrongly encoded. The same happens to attributes of artifacts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4798) ResourceResolver should extend java.io.Closeable
[ https://issues.apache.org/jira/browse/SLING-4798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-4798. - Resolution: Duplicate Fix Version/s: (was: Resource Resolver 1.2.6) ResourceResolver should extend java.io.Closeable Key: SLING-4798 URL: https://issues.apache.org/jira/browse/SLING-4798 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.2.4 Reporter: Robert Munteanu As discussed at [dev@sling : Make ResourceResolver implement Closeable|http://sling-dev.markmail.org/thread/fbvium36fnx6emol], the ResourceResolver should extend java.io.Closeable. This will allow its usage in the try-with-resources statement,while preserving compatibility with older versions ( java.io.Closeable was added in Java 1.5 ) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4751) New Observation Support
[ https://issues.apache.org/jira/browse/SLING-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14584681#comment-14584681 ] Carsten Ziegeler commented on SLING-4751: - One advantage of this new api, even if it would allow the same type of listeners as currently, is that the information can be fetched lazily. Right now, for each and every change, a repository read is necessary to get the resource type New Observation Support --- Key: SLING-4751 URL: https://issues.apache.org/jira/browse/SLING-4751 Project: Sling Issue Type: Improvement Components: API, JCR, ResourceResolver Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: API 2.10.0, Resource Resolver 1.2.6 Mail thread: http://mail-archives.apache.org/mod_mbox/sling-dev/201505.mbox/%3C555983F2.20402%40apache.org%3E Starting mail Right now, resources changes are propagated through event admin - which at the time sounded like a good idea. Over time, this has shown to be a bottle neck. Basically there are at least three problems: - the sender of the resource events does not know whether there is a receiver, therefore events for each and every change need to be sent - event objects are immutable and therefore all relevant data needs to be calculated upfront, even if it's not used. For example a resource event contains the resource type which needs to be fetched from the repository, even if no one is interested in it. - receivers of the events can't easily act on behalf of the user who initiated the change. I created a new listener api at [1] which defines a ResourceListener interface and some ways how to specify the events one is interested in. The user aware resource listener allows to act on behalf of the user (if that information is available). On the other side, a new service, the ObservationReporter [2] is defined. Resource providers report changes through this interface. The payload of such an event is an interface which allows for lazy retrieval of the information. We can also use this mechanism for compatibility and an implementation of the observation reporter might sent all events via the event admin. [1] https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api-v3/src/main/java/org/apache/sling/api/resource/observation/ [2] https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Sling Commons Scheduler
The vote passes with three +1 votes Thanks Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Sling Provisioning Model 1.2.0 and Apache Sling Slingstart Maven Plugin 1.2.0
The vote passes with three binding +1 votes and two non binding +1 votes Thanks Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Closed] (SLING-4782) Update to latest format from Apache Felix config admin
[ https://issues.apache.org/jira/browse/SLING-4782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-4782. --- Update to latest format from Apache Felix config admin -- Key: SLING-4782 URL: https://issues.apache.org/jira/browse/SLING-4782 Project: Sling Issue Type: Improvement Components: Tooling Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Sling Provisioning Model 1.2.0 The latest Apache Felix release allows to have multi value properties in multiple lines. We should support this See FELIX-4844 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4124) Bootstrap command file can't be appended
[ https://issues.apache.org/jira/browse/SLING-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-4124. --- Bootstrap command file can't be appended Key: SLING-4124 URL: https://issues.apache.org/jira/browse/SLING-4124 Project: Sling Issue Type: Improvement Components: Tooling Affects Versions: Sling Provisioning Model 1.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Sling Provisioning Model 1.2.0 As the contents for the bootstrap command file is currently a configuration, it can't be appended when inherited. It needs to repeat all entries from the model where it inherits from. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4691) throws information is missing on Resource, ResourceUtil, and ResourceResolver.
[ https://issues.apache.org/jira/browse/SLING-4691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-4691. - Resolution: Fixed I've added the missing throws information to Resource, ResourceUtil and ResourceResolver throws information is missing on Resource, ResourceUtil, and ResourceResolver. -- Key: SLING-4691 URL: https://issues.apache.org/jira/browse/SLING-4691 Project: Sling Issue Type: Improvement Components: API Affects Versions: API 2.9.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: API 2.10.0 The methods in the Resource interface are mssing the potential exceptions that might be thrown in the javadocs. For example listChildren forwards to the resource resolver which might throw IllegalStateException or SlingException Maybe other interfaces/classes are affected as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4752) New resource query API
[ https://issues.apache.org/jira/browse/SLING-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14584676#comment-14584676 ] Carsten Ziegeler commented on SLING-4752: - I've moved the prototype api to trunk New resource query API -- Key: SLING-4752 URL: https://issues.apache.org/jira/browse/SLING-4752 Project: Sling Issue Type: Improvement Components: API, JCR, ResourceResolver Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: API 2.10.0, Resource Resolver 1.2.6 Discussion thread: http://mail-archives.apache.org/mod_mbox/sling-dev/201505.mbox/%3C555983F6.7020100%40apache.org%3E Starting mail: The current resource query api has several problems: - it's using the JCR spec to define a query - it's not clear which queries are supported by providers - queries are string based - implementing queries in a resource provider is way too hard as this would require to implement the complete jcr query api. I've created a draft for a new, object based API at [1]. The main idea is to use a builder pattern to create Query objects. This are immutable and have a unique identifier. The QueryManager service can be used to execute a query in the context of a resource resolver. The manager delegates the query to the providers. As each Query object has this identifier, implementations can use this to cache the parsing of the query. In addition to the query object you can pass in query instructions to specify a limit or range for the query. Obviously this is a reduced set compared to the full fledged jcr search api, however it should be suitable for the majority of use cases. [1] https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api-v3/src/main/java/org/apache/sling/api/resource/query/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4750) New Resource Provider API
[ https://issues.apache.org/jira/browse/SLING-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14584674#comment-14584674 ] Carsten Ziegeler commented on SLING-4750: - I've moved the prototype api to trunk New Resource Provider API - Key: SLING-4750 URL: https://issues.apache.org/jira/browse/SLING-4750 Project: Sling Issue Type: Improvement Components: API, JCR, ResourceResolver Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: API 2.10.0, Resource Resolver 1.2.6 Mail thread from the mailing list: http://mail-archives.apache.org/mod_mbox/sling-dev/201505.mbox/%3C555983ED.1080800%40apache.org%3E Starting mail: The resource provider API has grown a lot over time and when we started with it we didn't really think about potential extensions of the api. Today, each time we add a new feature, we come up with a new marker interface. There is also the distinction between a resource provider (singleton/stateless) and the factory (creating stateful providers). Although the api is not intended to be used by the average resource api user (it's an extension), we put it in the same package. And there are more minor things. Therefore I think it's time to start a new API that is more future proof and solves the known problems. I've created a draft prototype at [1]. During the performance analysis by Joel he found out that getParent calls to a resource a pretty expensive as in the end these are string based. Therefore, e.g. the JCR implementation can't simply call getParent on a node and wrap it in a resource. Therefore I think we should add a getParent(Resource) method to the resource resolver and have a better way to handle this in a resource provider. Instead of having a resource provider and a resource provider factory, we define a single ResourceProvider which is a singleton. If this provider needs authentication and/or needs to keep state per user, the PROPERTY_AUTHENTICATE needs to be set to true and in this case the authenticate method is called. This one returns a data object which is passed in to each and every method. If auth is not required, the method is not called and null is passed in as the data object. For authentication, providers do not support login administrative anymore, just users and service users. A provider is mounted at a single root - no more support for mounting it at different path at the same time; and a provider always owns the root. So if a provider does not return a resource for a given path, no other provider is asked. This allows for improved implementations and resource resolving. If we decided that we need this for compatibility we can solve it differently. Instead of using marker interface, we define the ResourceProvider as an abstract class. This allows us to add new methods without breaking existing providers. Each method gets a ResolveContext, containing the resource resolver, the previously mentioned state data object and other things, e.g. the parameter support recently added to the resource resolving. In the future we can pass in additional data without breaking the interface. Apart from that the resource provider is similar to the aggregation of the already existing marker interfaces. There are two exceptions, observation and query which I'll handle in different emails. [1] https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api-v3/src/main/java/org/apache/sling/api/resource/provider/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Sling Installer Core 3.6.6
The vote passes with four +1 votes. Thanks Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Jenkins build is still unstable: sling-trunk-1.8 #1212
See https://builds.apache.org/job/sling-trunk-1.8/changes
[jira] [Updated] (SLING-4805) ResourceResolver should extend Closable interface.
[
https://issues.apache.org/jira/browse/SLING-4805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-4805:
Component/s: (was: JCR)
ResourceResolver should extend Closable interface.
--
Key: SLING-4805
URL: https://issues.apache.org/jira/browse/SLING-4805
Project: Sling
Issue Type: Improvement
Components: API
Affects Versions: API 2.9.0
Reporter: Michał Chudy
Fix For: API 2.10.0
While creating {{ResourceResolver}}, we have to remember to close it and code
looks like that:
{code}
ResourceResolver resourceResolver = null;
try {
resourceResolver =
resourceResolverFactory.getServiceResourceResolver(null);
} catch (LoginException e) {
LOGGER.error(Error during getting instance of ResourceResolver class,
e);
} finally {
if (resourceResolver != null) {
resourceResolver.close();
}
}
{code}
While making {{ResourceResolver}} additionally extend {{Closable}} (or
{{AutoClosable}}) interface, we could use try-with-resources Java 7 feature
and our code would be more concise, elegant, readable.
{code}
try (ResourceResolver resolver = factory.getServiceResourceResolver(null)) {
//do sth
}
{code}
(Please notice that {{Closable}} is still part of Java 6 API)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (SLING-4805) ResourceResolver should extend Closable interface.
[
https://issues.apache.org/jira/browse/SLING-4805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler reassigned SLING-4805:
---
Assignee: Carsten Ziegeler
ResourceResolver should extend Closable interface.
--
Key: SLING-4805
URL: https://issues.apache.org/jira/browse/SLING-4805
Project: Sling
Issue Type: Improvement
Components: API
Affects Versions: API 2.9.0
Reporter: Michał Chudy
Assignee: Carsten Ziegeler
Fix For: API 2.10.0
While creating {{ResourceResolver}}, we have to remember to close it and code
looks like that:
{code}
ResourceResolver resourceResolver = null;
try {
resourceResolver =
resourceResolverFactory.getServiceResourceResolver(null);
} catch (LoginException e) {
LOGGER.error(Error during getting instance of ResourceResolver class,
e);
} finally {
if (resourceResolver != null) {
resourceResolver.close();
}
}
{code}
While making {{ResourceResolver}} additionally extend {{Closable}} (or
{{AutoClosable}}) interface, we could use try-with-resources Java 7 feature
and our code would be more concise, elegant, readable.
{code}
try (ResourceResolver resolver = factory.getServiceResourceResolver(null)) {
//do sth
}
{code}
(Please notice that {{Closable}} is still part of Java 6 API)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4805) ResourceResolver should extend Closable interface.
[
https://issues.apache.org/jira/browse/SLING-4805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-4805:
Fix Version/s: API 2.10.0
ResourceResolver should extend Closable interface.
--
Key: SLING-4805
URL: https://issues.apache.org/jira/browse/SLING-4805
Project: Sling
Issue Type: Improvement
Components: API
Affects Versions: API 2.9.0
Reporter: Michał Chudy
Fix For: API 2.10.0
While creating {{ResourceResolver}}, we have to remember to close it and code
looks like that:
{code}
ResourceResolver resourceResolver = null;
try {
resourceResolver =
resourceResolverFactory.getServiceResourceResolver(null);
} catch (LoginException e) {
LOGGER.error(Error during getting instance of ResourceResolver class,
e);
} finally {
if (resourceResolver != null) {
resourceResolver.close();
}
}
{code}
While making {{ResourceResolver}} additionally extend {{Closable}} (or
{{AutoClosable}}) interface, we could use try-with-resources Java 7 feature
and our code would be more concise, elegant, readable.
{code}
try (ResourceResolver resolver = factory.getServiceResourceResolver(null)) {
//do sth
}
{code}
(Please notice that {{Closable}} is still part of Java 6 API)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4805) ResourceResolver should extend Closable interface.
[
https://issues.apache.org/jira/browse/SLING-4805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14584663#comment-14584663
]
Michał Chudy commented on SLING-4805:
-
:-) What a timing! Thanks!
ResourceResolver should extend Closable interface.
--
Key: SLING-4805
URL: https://issues.apache.org/jira/browse/SLING-4805
Project: Sling
Issue Type: Improvement
Components: API
Affects Versions: API 2.9.0
Reporter: Michał Chudy
Assignee: Carsten Ziegeler
Fix For: API 2.10.0
While creating {{ResourceResolver}}, we have to remember to close it and code
looks like that:
{code}
ResourceResolver resourceResolver = null;
try {
resourceResolver =
resourceResolverFactory.getServiceResourceResolver(null);
} catch (LoginException e) {
LOGGER.error(Error during getting instance of ResourceResolver class,
e);
} finally {
if (resourceResolver != null) {
resourceResolver.close();
}
}
{code}
While making {{ResourceResolver}} additionally extend {{Closable}} (or
{{AutoClosable}}) interface, we could use try-with-resources Java 7 feature
and our code would be more concise, elegant, readable.
{code}
try (ResourceResolver resolver = factory.getServiceResourceResolver(null)) {
//do sth
}
{code}
(Please notice that {{Closable}} is still part of Java 6 API)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4751) New Observation Support
[ https://issues.apache.org/jira/browse/SLING-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14584675#comment-14584675 ] Carsten Ziegeler commented on SLING-4751: - I've moved the prototype api to trunk New Observation Support --- Key: SLING-4751 URL: https://issues.apache.org/jira/browse/SLING-4751 Project: Sling Issue Type: Improvement Components: API, JCR, ResourceResolver Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: API 2.10.0, Resource Resolver 1.2.6 Mail thread: http://mail-archives.apache.org/mod_mbox/sling-dev/201505.mbox/%3C555983F2.20402%40apache.org%3E Starting mail Right now, resources changes are propagated through event admin - which at the time sounded like a good idea. Over time, this has shown to be a bottle neck. Basically there are at least three problems: - the sender of the resource events does not know whether there is a receiver, therefore events for each and every change need to be sent - event objects are immutable and therefore all relevant data needs to be calculated upfront, even if it's not used. For example a resource event contains the resource type which needs to be fetched from the repository, even if no one is interested in it. - receivers of the events can't easily act on behalf of the user who initiated the change. I created a new listener api at [1] which defines a ResourceListener interface and some ways how to specify the events one is interested in. The user aware resource listener allows to act on behalf of the user (if that information is available). On the other side, a new service, the ObservationReporter [2] is defined. Resource providers report changes through this interface. The payload of such an event is an interface which allows for lazy retrieval of the information. We can also use this mechanism for compatibility and an implementation of the observation reporter might sent all events via the event admin. [1] https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api-v3/src/main/java/org/apache/sling/api/resource/observation/ [2] https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4677) Allow to start in debug mode through a mojo parameter similar to debugForkedProcess
[ https://issues.apache.org/jira/browse/SLING-4677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-4677. --- Allow to start in debug mode through a mojo parameter similar to debugForkedProcess --- Key: SLING-4677 URL: https://issues.apache.org/jira/browse/SLING-4677 Project: Sling Issue Type: Improvement Components: Maven Plugins and Archetypes Affects Versions: Slingstart Maven Plugin 1.1.0 Reporter: Konrad Windszus Assignee: Konrad Windszus Fix For: Slingstart Maven Plugin 1.2.0 Attachments: SLING-4677-v1.diff It would be good to have a mojo parameter similar to https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#debugForkedProcess to ease the debugging of Sling. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4635) Topology related jobs shouldn't be scheduled if topology is unclear/not available
[ https://issues.apache.org/jira/browse/SLING-4635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-4635. --- Topology related jobs shouldn't be scheduled if topology is unclear/not available - Key: SLING-4635 URL: https://issues.apache.org/jira/browse/SLING-4635 Project: Sling Issue Type: Bug Components: Commons Affects Versions: Commons Scheduler 2.4.6 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Commons Scheduler 2.4.8 If a job is scheduled to be run only on the leader or only on a single instance, it is currently scheduled even if the topology is not available or changing. This is wrong as this can lead to the job being scheduled more than once in a cluster in such situations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4126) Provide a mechanism to merge configurations
[ https://issues.apache.org/jira/browse/SLING-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-4126. --- Provide a mechanism to merge configurations --- Key: SLING-4126 URL: https://issues.apache.org/jira/browse/SLING-4126 Project: Sling Issue Type: Improvement Components: Tooling Affects Versions: Sling Provisioning Model 1.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Sling Provisioning Model 1.2.0 Right now, if a model is merged a configuration can only be overwritten which means if an overlay just wants to add or change a single parameter, it has to repeat the whole configuration -- This message was sent by Atlassian JIRA (v6.3.4#6332)
