[jira] [Resolved] (SLING-4086) Sling Mocks: SlingHttpServlerRequest should support getResourceBundle() methods
[ https://issues.apache.org/jira/browse/SLING-4086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-4086. --- Resolution: Fixed Completed: At revision: 1633444 methods return an empty ResourceBundle by default. if a ResourceBundleProvider is registered in OSGi context this is used to query for a resource bundle. Sling Mocks: SlingHttpServlerRequest should support getResourceBundle() methods --- Key: SLING-4086 URL: https://issues.apache.org/jira/browse/SLING-4086 Project: Sling Issue Type: Improvement Components: Testing Affects Versions: Testing Sling Mock 1.0.0 Reporter: Stefan Seifert Assignee: Stefan Seifert Priority: Minor Labels: mocks Fix For: Testing Sling Mock 1.0.2 currently the getResourceBundle() methods throw UnsupportedOperationException. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Sling Resource Resolver Mock 1.0.0, JCR Mock 1.0.0, OSGi Mock 1.0.0, Sling Mock 1.0.0, Sling Mock Jackrabbit 0.1.0
+1 Robert On Tue, Oct 21, 2014 at 10:24 PM, Stefan Seifert sseif...@pro-vision.de wrote: thanks tommaso for checking this ... but we still need one binding (PMC) vote for this. stefan -Original Message- From: Tommaso Teofili [mailto:tommaso.teof...@gmail.com] Sent: Tuesday, October 21, 2014 8:22 AM To: dev@sling.apache.org Subject: Re: [VOTE] Release Apache Sling Resource Resolver Mock 1.0.0, JCR Mock 1.0.0, OSGi Mock 1.0.0, Sling Mock 1.0.0, Sling Mock Jackrabbit 0.1.0 +1 Tommaso 2014-10-17 10:56 GMT+02:00 Stefan Seifert sseif...@pro-vision.de: Hi, We solved 4 issues in this release of Resource Resolver Mock 1.0.0: https://issues.apache.org/jira/browse/SLING/fixforversion/12328721 First release of this modules: JCR Mock 1.0.0 https://issues.apache.org/jira/browse/SLING/fixforversion/12328830 OSGi Mock 1.0.0 https://issues.apache.org/jira/browse/SLING/fixforversion/12328831 Sling Mock 1.0.0 https://issues.apache.org/jira/browse/SLING/fixforversion/12328832 Sling Mock Jackrabbit 0.1.0 *) https://issues.apache.org/jira/browse/SLING/fixforversion/12328833 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1140/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1140 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. stefan *) this is still experimental, thus only a 0.1.0 release.
[jira] [Created] (SLING-4087) Sling Parent: Move m2e lifecycle mappings to separate profile
Stefan Seifert created SLING-4087:
-
Summary: Sling Parent: Move m2e lifecycle mappings to separate
profile
Key: SLING-4087
URL: https://issues.apache.org/jira/browse/SLING-4087
Project: Sling
Issue Type: Improvement
Components: General
Affects Versions: Parent 22
Reporter: Stefan Seifert
Assignee: Stefan Seifert
Priority: Trivial
Fix For: Parent 23
currently several maven commands like {{mvn eclipse:eclipse}} complain about a
missing maven dependency {{org.eclipse.m2e:lifecycle-mapping:1.0.0}}. they
work, but this warning is annoying.
there is an easy solution for this by moving them to a separate provile
activted by a m2e.version property - see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=367870#c18
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-4087) Sling Parent: Move m2e lifecycle mappings to separate profile
[
https://issues.apache.org/jira/browse/SLING-4087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert resolved SLING-4087.
---
Resolution: Fixed
Completed: At revision: 1633454
Sling Parent: Move m2e lifecycle mappings to separate profile
-
Key: SLING-4087
URL: https://issues.apache.org/jira/browse/SLING-4087
Project: Sling
Issue Type: Improvement
Components: General
Affects Versions: Parent 22
Reporter: Stefan Seifert
Assignee: Stefan Seifert
Priority: Trivial
Fix For: Parent 23
currently several maven commands like {{mvn eclipse:eclipse}} complain about
a missing maven dependency {{org.eclipse.m2e:lifecycle-mapping:1.0.0}}. they
work, but this warning is annoying.
there is an easy solution for this by moving them to a separate provile
activted by a m2e.version property - see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=367870#c18
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[RESULT] [VOTE] Release Apache Sling Resource Resolver Mock 1.0.0, JCR Mock 1.0.0, OSGi Mock 1.0.0, Sling Mock 1.0.0, Sling Mock Jackrabbit 0.1.0
Hi, The vote has passed with the following result : +1 (binding): Carsten Ziegeler, Daniel Klco, Robert Munteanu +1 (non binding): Tommaso Teofili @any PMC member: please promote the releases to maven central and dist, i'll take care of JIRA and the website. stefan
[jira] [Closed] (SLING-4033) MockResourceResolver: Lower Sling API Dependency to 2.4.0
[ https://issues.apache.org/jira/browse/SLING-4033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-4033. - Assignee: (was: Stefan Seifert) MockResourceResolver: Lower Sling API Dependency to 2.4.0 - Key: SLING-4033 URL: https://issues.apache.org/jira/browse/SLING-4033 Project: Sling Issue Type: Improvement Components: Testing Reporter: Stefan Seifert Priority: Minor Fix For: Testing ResourceResolver Mock 1.0.0 following the discussion on the mailing list the resourceresolver mock implementation should depend on a Sling API as lowest as possible (2.4.0 is the target). methods added in later versions of the API should be present, but without @Override annotation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4040) MockResourceResolver: Return null for getResource für null path
[ https://issues.apache.org/jira/browse/SLING-4040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-4040. - Assignee: (was: Stefan Seifert) MockResourceResolver: Return null for getResource für null path --- Key: SLING-4040 URL: https://issues.apache.org/jira/browse/SLING-4040 Project: Sling Issue Type: Bug Components: Testing Affects Versions: Testing ResourceResolver Mock 0.3.0 Reporter: Stefan Seifert Fix For: Testing ResourceResolver Mock 1.0.0 if a null string path is passed to ResourceResolver.getResource method null should be returned - same behavior when using JCR resource implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4039) MockResourceResolver: Support ISO8601 date string to Calendar conversion
[ https://issues.apache.org/jira/browse/SLING-4039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-4039. - Assignee: (was: Stefan Seifert) MockResourceResolver: Support ISO8601 date string to Calendar conversion Key: SLING-4039 URL: https://issues.apache.org/jira/browse/SLING-4039 Project: Sling Issue Type: Improvement Components: Testing Affects Versions: Testing ResourceResolver Mock 0.3.0 Reporter: Stefan Seifert Fix For: Testing ResourceResolver Mock 1.0.0 the default sing JCR resource implementation supports automatically converting String values that are conformant to ISO8601 date format to Calendar (and Date) objects. this should be supported by the mock as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-4038) MockResourceResolver: Normalize path in getResource(String) method
[
https://issues.apache.org/jira/browse/SLING-4038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert closed SLING-4038.
-
Assignee: (was: Stefan Seifert)
MockResourceResolver: Normalize path in getResource(String) method
--
Key: SLING-4038
URL: https://issues.apache.org/jira/browse/SLING-4038
Project: Sling
Issue Type: Bug
Components: Testing
Affects Versions: Testing ResourceResolver Mock 0.3.0
Reporter: Stefan Seifert
Fix For: Testing ResourceResolver Mock 1.0.0
the path passed in to {{ResourceResolver.getResource(String)}} should be
normalized before trying to access the internal maps to get the resource.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (SLING-4042) Testing: Donate sling-mock, jcr-mock, osgi-mock implementation
[ https://issues.apache.org/jira/browse/SLING-4042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-4042. - Assignee: (was: Stefan Seifert) Testing: Donate sling-mock, jcr-mock, osgi-mock implementation -- Key: SLING-4042 URL: https://issues.apache.org/jira/browse/SLING-4042 Project: Sling Issue Type: New Feature Components: Testing Reporter: Stefan Seifert Fix For: Testing JCR Mock 1.0.0, Testing OSGi Mock 1.0.0, Testing Sling Mock 1.0.0, Testing Sling Mock Jackrabbit 0.1.0 donate a at suite of mocking libraries to run OSGi/SCR, JCR and esp. Sling in a simulated in-memory environment for unit tests, ensuring minimal setup time. it uses either a mocked in-memory JCR, or the resourceresolver-mock implementation that is already part of the sling project. additional convenience features like bulk-loading JSON content and binaries into the simulated resource tree via a content loader makes it easy setting up complex text fixtures for your unit tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build became unstable: sling-trunk-1.6 » Apache Sling Resource Access Security Integration Tests #2688
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.resourceaccesssecurity.it/2688/
Jenkins build is back to stable : sling-trunk-1.6 » Apache Sling Installer Integration Tests #2688
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.installer.it/2688/
Jenkins build is still unstable: sling-trunk-1.6 #2688
See https://builds.apache.org/job/sling-trunk-1.6/changes
Jenkins build became unstable: sling-trunk-1.6 » Apache Sling Event Support #2688
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.event/2688/
[jira] [Commented] (SLING-4026) Sling Models Race Condition
[
https://issues.apache.org/jira/browse/SLING-4026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14179097#comment-14179097
]
Stefan Seifert commented on SLING-4026:
---
update which version - of your own bundle containing a component like
ExampleComponent? should work.
can you provide a simple maven project which allows to reproduce the problem
outside your project?
Sling Models Race Condition
---
Key: SLING-4026
URL: https://issues.apache.org/jira/browse/SLING-4026
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: Sling Models Implementation 1.1.0
Reporter: JBodkin
Labels: models
During initialization of a bundle, it is possible to encounter a race
condition in which the BundleTrackerCustomizer::addingBundle(Bundle bundle,
BundleEvent event) is triggered after the bundle has begun initialization of
a immediate component.
{code:java}
@Component(immediate = true)
@Service
public class ExampleImpl {
@Activate
public void activate(ComponentContext context) {
Resource resource =
// Race condition possible here... Could be executed before the
BundleTracker (ModelPackageBundleListener)
SlingModelExample example = resource.adaptTo(SlingModelExample);
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Jenkins build became unstable: sling-trunk-1.6 » Apache Sling Installer Integration Tests #2689
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.installer.it/2689/
Jenkins build is back to stable : sling-trunk-1.6 » Apache Sling Resource Access Security Integration Tests #2689
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.resourceaccesssecurity.it/2689/
Jenkins build is back to stable : sling-trunk-1.6 » Apache Sling Event Support #2689
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.event/2689/
Jenkins build is still unstable: sling-trunk-1.6 #2689
See https://builds.apache.org/job/sling-trunk-1.6/changes
[jira] [Reopened] (SLING-4083) Sling Models: Enable SlingObject injector to inject all context objects when a request is attached to the current thread
[ https://issues.apache.org/jira/browse/SLING-4083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson reopened SLING-4083: --- [~sseif...@pro-vision.de] I think this warrants some discussion on sling-dev. I have two concerns. 1) This ThreadLocal filter doesn't seem to be appropriate as part of Sling Models. If such a filter is going to be part of Sling it should IMHO be done in the engine and then used across the codebase. Of course, then we need to figure out how to work with old versions of the Engine bundle, but that's a solveable problem. 2) In the past, there have been objections to these types of ThreadLocal filters (see, for example, http://sling.markmail.org/thread/epn5vdw3fkmpsk6w). This isn't to say that we shouldn't have this filter, but I think it is important (and Apache way-ish) to at least try to reconcile this on sling-dev before going to far. NOTE - I'm *not* asking you to revert your code, just to start a discussion about this change. Sling Models: Enable SlingObject injector to inject all context objects when a request is attached to the current thread Key: SLING-4083 URL: https://issues.apache.org/jira/browse/SLING-4083 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Sling Models Implementation 1.1.0 Reporter: Stefan Seifert Assignee: Stefan Seifert Labels: models Fix For: Sling Models Impl 1.2.0 The SlingObjectInjector should support injecting all context objects (Resource, ResourceResolver, Request, Response, SlingScriptHelper) always, and not only when derivable from the current adaptable. in sling models 1.1.0 the injection of most of those objects fails e.g. when adapting from a resource resolver because the request object is not available. thus if a developer uses a @SlingObject annotation he has to be aware of those implementation details when the context objects are available and when not. if used from a scripting language light Sightly which first tries to adapt a model from the current resource, and after that from the current request things get worse. if a model is adapted in a thread initiated from a request all injections should be always supported. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
