[jira] [Commented] (SLING-4283) Use config from builder in testing application
[
https://issues.apache.org/jira/browse/SLING-4283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14265765#comment-14265765
]
Chetan Mehrotra commented on SLING-4283:
Maven Launchpad Plugin does have support for extracting the zipped config and
use it as part of Sling launch [1]. To make use of that following dependency
needs to be added
{code:xml}
dependency
groupIdorg.apache.sling/groupId
artifactIdorg.apache.sling.launchpad/artifactId
version8-SNAPSHOT/version
typepartialbundlelist/type
classifierbundlelist/classifier
/dependency
{code}
This triggers unpacking of the config files to {{target/tmpConfigDir}}. However
current logic does not handle subdirectory in config folder [2] (also see
comment at handleConfigSubpath in [2]) due to which these config files are not
picked up.
{code:title=BundleListContentProvider.java|linenumbers=true|firstline=224}
private IteratorString handleConfigSubpath(String path) {
// We don't handle config subpaths for now, but do not
// warn if we're asked for the children of a file, just
// return empty in that case
final File f = getConfigFile(path);
if(!f.exists()) {
getLog().warn(BundleListContentProvider cannot get children of
config path: + path);
}
return EMPTY_STRING_LIST.iterator();
}
{code}
Looking at the code it appears that sub directories can easily be support by
changing the login in [2] to not filter out directories and fix the logic in
{{handleConfigSubpath}} . Sling launchpad would then do the required traversal
[~bdelacretaz] [~cziegeler] Thoughts?
Another workaround would be to set {{sling.fileinstall.dir}} in
testing/src/test/config/sling.properties and then using maven, unpack the
config in that folder
Or another shortterm workaround is to copy the required config files. Currently
we have anyway copied the SegmentNodeStore service config so we can add few
more and fix the issue in Launchpad plugin going forward!
[1]
https://github.com/apache/sling/blob/trunk/tooling/maven/maven-launchpad-plugin/src/main/java/org/apache/sling/maven/projectsupport/AbstractUsingBundleListMojo.java#L289-300
[2]
https://github.com/apache/sling/blob/trunk/tooling/maven/maven-launchpad-plugin/src/main/java/org/apache/sling/maven/projectsupport/BundleListContentProvider.java#L72-93
Use config from builder in testing application
--
Key: SLING-4283
URL: https://issues.apache.org/jira/browse/SLING-4283
Project: Sling
Issue Type: Sub-task
Components: Testing
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Fix For: Launchpad Testing 7
The testing application does not use the config present in
{{org.apache.sling.launchpad}}. This cause test failures when running with
Oak as required configuration is not installed [1]
As a fix the testing module should use the config from launchpad module
[1] http://markmail.org/thread/xfljme3swaexpcvw
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[VOTE] Release Apache Sling Installer Factory Subsystems 1.0.0
Hi, it's time for a first release of the subsystems support to our OSGi installer. Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1159/ 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 1159 /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. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Sling Installer Factory Subsystems 1.0.0
Am 06.01.15 um 08:54 schrieb Carsten Ziegeler: Hi, it's time for a first release of the subsystems support to our OSGi installer. Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1159/ 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 1159 /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. Regards Carsten +1 Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Commented] (SLING-4283) Use config from builder in testing application
[
https://issues.apache.org/jira/browse/SLING-4283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14265793#comment-14265793
]
Carsten Ziegeler commented on SLING-4283:
-
The launchpad plugin code dates back to a time before we added run mode support
for the configurations; at that time we didnt have sub directories.
Unfortunately, when we added run mode support, we forgot to change this code.
So +1 for supporting sub directories in the plugin
Use config from builder in testing application
--
Key: SLING-4283
URL: https://issues.apache.org/jira/browse/SLING-4283
Project: Sling
Issue Type: Sub-task
Components: Testing
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Fix For: Launchpad Testing 7
The testing application does not use the config present in
{{org.apache.sling.launchpad}}. This cause test failures when running with
Oak as required configuration is not installed [1]
As a fix the testing module should use the config from launchpad module
[1] http://markmail.org/thread/xfljme3swaexpcvw
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-3652) Sling Job Consumer Manager : Distribute config should be disabled by default
[ https://issues.apache.org/jira/browse/SLING-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14265805#comment-14265805 ] Carsten Ziegeler commented on SLING-3652: - [~shroti] I tried your setup by starting to instances, going to the web console of the first instance and then changing the job consumer manager configuration. This change is not propagated to the other instances. So at least with doing it this way it works as expected. Did you test it differently? If so please list all steps after the instances are up and running to reproduce it. Thanks Sling Job Consumer Manager : Distribute config should be disabled by default Key: SLING-3652 URL: https://issues.apache.org/jira/browse/SLING-3652 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Event 3.3.10 Reporter: Ashutosh Shroti Assignee: Amit Gupta Sling Job Consumer Manager service have an following flag: Distribute config - disabled This should be disabled by default. Use Case: While configuring author instances in the cluster, config changes like disable the listener on topic com/adobe/granite/workflow/offloading should be local to an instance. Hence above mentioned flag should be disabled by default to prevent config changes to local instance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Simplify debugging integration test failures
Hi Team, Often we see that some integration test starts failing on CI server but does not fail when ran individually on local setup. This can happen due to various reasons like data created from other test influencing the failing test logic, issue in some other module etc. Debugging such failure takes time as the CI output does not provide much info and in many cases does not provide access to server side logs which contain most relevant data. Even if you can get access to server side logs it take time to determine the logs which were created while the test in question was being executed as the logs have lot of noise. It would be lot faster if upon some integration test failure the test can dump the server side logs (only the logs created during that test execution) locally. This would allow a developer to directly get all related data within CI server provided data itself. I have implemented one approach in SLING-4280 [1]. Kindly review the proposed approach !! Chetan Mehrotra [1] https://issues.apache.org/jira/browse/SLING-4280
[jira] [Resolved] (SLING-4278) Add package info file to testing tools
[
https://issues.apache.org/jira/browse/SLING-4278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved SLING-4278.
Resolution: Fixed
Added files with http://svn.apache.org/r1649489
Add package info file to testing tools
--
Key: SLING-4278
URL: https://issues.apache.org/jira/browse/SLING-4278
Project: Sling
Issue Type: Task
Components: Testing
Affects Versions: org.apache.sling.testing.tools 1.0.8
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
Fix For: org.apache.sling.testing.tools 1.0.10
Currently building the testing/tools module generates following warning
{noformat}
[WARNING] org.apache.sling.testing.tools.http: Excessive version increase;
detected 1.0.9, suggested 1.0.8
[WARNING] org.apache.sling.testing.tools.http: Version has been increased but
analysis detected no changes; detected 1.0.9, suggested 1.0.8
[WARNING] org.apache.sling.testing.tools.jarexec: Excessive version increase;
detected 1.0.9, suggested 1.0.8
[WARNING] org.apache.sling.testing.tools.jarexec: Version has been increased
but analysis detected no changes; detected 1.0.9, suggested 1.0.8
[WARNING] org.apache.sling.testing.tools.junit: Excessive version increase;
detected 1.0.9, suggested 1.0.8
[WARNING] org.apache.sling.testing.tools.junit: Version has been increased
but analysis detected no changes; detected 1.0.9, suggested 1.0.8
[WARNING] org.apache.sling.testing.tools.retry: Excessive version increase;
detected 1.0.9, suggested 1.0.8
[WARNING] org.apache.sling.testing.tools.retry: Version has been increased
but analysis detected no changes; detected 1.0.9, suggested 1.0.8
[WARNING] org.apache.sling.testing.tools.serversetup: Excessive version
increase; detected 1.0.9, suggested 1.0.8
[WARNING] org.apache.sling.testing.tools.serversetup: Version has been
increased but analysis detected no changes; detected 1.0.9, suggested 1.0.8
[WARNING] org.apache.sling.testing.tools.sling: Excessive version increase;
detected 1.0.9, suggested 1.0.8
[WARNING] org.apache.sling.testing.tools.sling: Version has been increased
but analysis detected no changes; detected 1.0.9, suggested 1.0.8
{noformat}
This is due to package export version being set to module version. Instead
version should be provided explicitly via package-info files
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
OSGi config for testing app
Hi, As part of fixing Oak integration with Sling I have added couple of OSGi config in launchpad/builder project [1]. With those the testcase pass when ran against a Sling instance created from the launchpad/builder project However the testcase fails when run as part of launchpad/testing project. This happens because the testing project probably does not inherit the OSGi config and only inherits the bundlelist. So should I also copy the same set of OSGi config to testing project [2]? Chetan Mehrotra [1] https://github.com/apache/sling/tree/trunk/launchpad/builder/src/main/config/oak [2] https://github.com/apache/sling/tree/trunk/launchpad/testing/src/main/config
[jira] [Commented] (SLING-4275) Review of the Sightly API
[
https://issues.apache.org/jira/browse/SLING-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264423#comment-14264423
]
Felix Meschberger commented on SLING-4275:
--
Thanks, [~cziegeler]. I would also like to have [~radu.cotescu] chime in.
Just one thing:
bq. what about ValueMap?
{{ValueMap extends Map}} and thus does not make it easier. Also since the
properties are evaluated in the context of expressions of the form
$\{obj.somesub.prop\} parsed by Sightly a {{ValueMap}} propably does not add
much value.
Review of the Sightly API
-
Key: SLING-4275
URL: https://issues.apache.org/jira/browse/SLING-4275
Project: Sling
Issue Type: Task
Components: Scripting
Reporter: Carsten Ziegeler
Fix For: Scripting Sightly Engine 1.0.0
I have some comments about the public Sightly API:
1. There are several exceptions, like SightlyException,
RuntimeExtensionException, SightlyUseException - are these really required?
The API does not mention any method/interface throwing such an exception
2. RuntimeExtension and ExtensionInstance - I think we can get rid of the
RuntimeExtension interface and simply pass the RenderContext in
ExtensionInstance#call.
3. The purpose of the Record interface is a little bit unclear to me. In
addition it has a T get(String) method while properties returns a
SetString. I guess the engine supports a Map, so maybe we can get rid of
this interface?
4. ResourceResolution seems to contain methods for getting scripts. Isn't
this some functionalty the existing ServletResolver component provides? Or if
not, shouldn't we move this to the Sling API?
5. Many of the methods in the RenderContext are Object traversal and value
conversion methods. I think this needs to go into a separate service (and
maybe package)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Jenkins build is still unstable: sling-oak-it-1.6 #258
See https://builds.apache.org/job/sling-oak-it-1.6/258/
[jira] [Created] (SLING-4280) Enable dumping of remote server logs in case of test failures
Chetan Mehrotra created SLING-4280: -- Summary: Enable dumping of remote server logs in case of test failures Key: SLING-4280 URL: https://issues.apache.org/jira/browse/SLING-4280 Project: Sling Issue Type: New Feature Components: Testing Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra In case of large test suite running on CI server its hard to make out which logs were created due to execution of which testcase. This makes determining the cause of testcase failure difficult. Often the server logs are also not avialable once the build is completed and only source of information is system out logs captured via junit framework on client side. This debugging process can be made simpler if the testcase also dumps the server side logs generated while that testcase executes locally upon failure -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: OSGi config for testing app
Hi Chetan, On Mon, Jan 5, 2015 at 10:43 AM, Chetan Mehrotra chetan.mehro...@gmail.com wrote: ...So should I also copy the same set of OSGi config to testing project [2]? ... Copying sounds bad...how can that be automated? Maybe have the configs in a different artifact that the testing module expands before starting? -Bertrand [1] https://github.com/apache/sling/tree/trunk/launchpad/builder/src/main/config/oak [2] https://github.com/apache/sling/tree/trunk/launchpad/testing/src/main/config
[jira] [Updated] (SLING-4280) Enable dumping of remote server logs in case of test failures
[
https://issues.apache.org/jira/browse/SLING-4280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated SLING-4280:
---
Attachment: test-fail-output.txt
SLING-4280.patch
[Patch|^SLING-4280.patch] which provides a JUnit Rule and a Servlet to enable
dumping of remote server logs. It works in following way
# {{RemoteLogDumper}} - A junit rule implementation which exposes the current
executing test description to Slf4j MDC (a threadlocal storage)
# Propagation of test description via HTTP Headers - Whenever the testcase
makes a remote call via HTTP Client then the associated test description is
sent as part of following HTTP headers
## {{sling.test.class}} - Header capturing the testcase
## {{sling.test.name}} - Header capturing the testname
# Server side log collection - On server side a {{TestLogServlet}} (registered
at {{/system/sling/testlog}}) collects the logs in an in memory buffer. The
buffer gets reset for every new test execution. This allows capturing of the
logs relevant to currently executing test. These logs are then exposed via the
{{TestLogServlet}}
# Upon testcase failure the {{RemoteLogDumper}} would fetch the logs from the
{{TestLogServlet}} and would dump it as part of system output. See [attached
sample|^test-fail-output.txt]
*Usage*
On client side the testcase needs to just add following rule
{code}
public class AuthenticationResponseCodeTest {
@Rule
public TestRule logRule = new RemoteLogDumper();
...
@Test
public void testValidatingCorrectFormCredentials() throws Exception {
... //Make remote calls
}
}
{code}
*Propagation of test description via HTTP Headers*
To enable propoagation of test description via HTTP headers the approach
differs based on HTTP Client version.
For Http Client 3.x (used in
org.apache.sling.commons.testing.integration.HttpTestBase which is used by
majority of integration-test) the headers are added via overriding the execute
calls. As required changes are done in {{HttpTestBase}} the test classes would
not be required to do much
For Http Client 4.x a {{TestDescriptionInterceptor}} is provided which should
be registered with the HttpClient whereever it is instantiated
{code}
DefaultHttpClient httpClient = new DefaultHttpClient();
httpClient.addRequestInterceptor(new TestDescriptionInterceptor());
{code}
Enable dumping of remote server logs in case of test failures
-
Key: SLING-4280
URL: https://issues.apache.org/jira/browse/SLING-4280
Project: Sling
Issue Type: New Feature
Components: Testing
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Attachments: SLING-4280.patch, test-fail-output.txt
In case of large test suite running on CI server its hard to make out which
logs were created due to execution of which testcase. This makes determining
the cause of testcase failure difficult. Often the server logs are also not
avialable once the build is completed and only source of information is
system out logs captured via junit framework on client side.
This debugging process can be made simpler if the testcase also dumps the
server side logs generated while that testcase executes locally upon failure
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: OSGi config for testing app
Not sure. is there any support present in Maven launchpad tooling for that? Chetan Mehrotra On Mon, Jan 5, 2015 at 4:04 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi Chetan, On Mon, Jan 5, 2015 at 10:43 AM, Chetan Mehrotra chetan.mehro...@gmail.com wrote: ...So should I also copy the same set of OSGi config to testing project [2]? ... Copying sounds bad...how can that be automated? Maybe have the configs in a different artifact that the testing module expands before starting? -Bertrand [1] https://github.com/apache/sling/tree/trunk/launchpad/builder/src/main/config/oak [2] https://github.com/apache/sling/tree/trunk/launchpad/testing/src/main/config
[jira] [Resolved] (SLING-4009) Multiple endpoint delivery should be fault tolerant
[ https://issues.apache.org/jira/browse/SLING-4009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marius Petria resolved SLING-4009. -- Resolution: Fixed Fix Version/s: Content Distribution 0.1.0 Multiple endpoint delivery should be fault tolerant --- Key: SLING-4009 URL: https://issues.apache.org/jira/browse/SLING-4009 Project: Sling Issue Type: Bug Components: Distribution Reporter: Marius Petria Assignee: Marius Petria Fix For: Content Distribution 0.1.0 Replication can deliver a package to multiple endpoints using a remoteimporter. We need a way to enable retries for a an endpoint for which delivery failed without delaying the delivery for the other endpoints. The obvious solution will be to have dedicated queues for each endpoint. The problems with that: 1. agent has no visibility over endpoints which are configured at importer level. 2. if packages can be added to multiple queues then we need a reference counting mechanism for packages. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (SLING-4009) Multiple endpoint delivery should be fault tolerant
[ https://issues.apache.org/jira/browse/SLING-4009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marius Petria reassigned SLING-4009: Assignee: Marius Petria Multiple endpoint delivery should be fault tolerant --- Key: SLING-4009 URL: https://issues.apache.org/jira/browse/SLING-4009 Project: Sling Issue Type: Bug Components: Distribution Reporter: Marius Petria Assignee: Marius Petria Fix For: Content Distribution 0.1.0 Replication can deliver a package to multiple endpoints using a remoteimporter. We need a way to enable retries for a an endpoint for which delivery failed without delaying the delivery for the other endpoints. The obvious solution will be to have dedicated queues for each endpoint. The problems with that: 1. agent has no visibility over endpoints which are configured at importer level. 2. if packages can be added to multiple queues then we need a reference counting mechanism for packages. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4009) Multiple endpoint delivery should be fault tolerant
[ https://issues.apache.org/jira/browse/SLING-4009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264475#comment-14264475 ] Marius Petria commented on SLING-4009: -- Committed revision 1649499. A queue is created for each endpoint with the name specified in the endpoint description. https://github.com/apache/sling/blob/cf076879f572d9976fd002d67e48108af5992eaa/contrib/extensions/distribution/sample/src/main/resources/SLING-CONTENT/libs/sling/distribution/settings.author/agents/publish-multiple.json Multiple endpoint delivery should be fault tolerant --- Key: SLING-4009 URL: https://issues.apache.org/jira/browse/SLING-4009 Project: Sling Issue Type: Bug Components: Distribution Reporter: Marius Petria Fix For: Content Distribution 0.1.0 Replication can deliver a package to multiple endpoints using a remoteimporter. We need a way to enable retries for a an endpoint for which delivery failed without delaying the delivery for the other endpoints. The obvious solution will be to have dedicated queues for each endpoint. The problems with that: 1. agent has no visibility over endpoints which are configured at importer level. 2. if packages can be added to multiple queues then we need a reference counting mechanism for packages. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build is back to stable : sling-trunk-1.7 #1277
See https://builds.apache.org/job/sling-trunk-1.7/1277/changes
[jira] [Commented] (SLING-4275) Review of the Sightly API
[
https://issues.apache.org/jira/browse/SLING-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264346#comment-14264346
]
Carsten Ziegeler commented on SLING-4275:
-
{quote}
* SightlyException is the root exception of all of Sightly.
* SightlyUseException may be thrown by the UseProvider API. Respective JavaDoc
mention is missing
* RuntimeExtensionException may be thrown by the RuntimeExtension API.
Respective JavaDoc is missing
{quote}
Right, but do we really need these different runtime exceptions? Each service
having it's own runtime exception seems like a vaste to me, especially as the
caller does not do anything with such exceptions.
bq. RuntimeExtension.provide is called once per script evaluation while
ExtensionInstance objects may be called for each occurrence of the extension's
use in the script. As such this is kind of a caching mechanism.
As ExtensionInstance has a single method, I think we could go without this
extra layer of object caching and go with a singleton
bq. The Record interface supports for simplified property access in a much
simpler way than the Map interface would allow. Also Pojo's in use
attributes/statements may implement the Record interface to actually inject
properties into the current evaluation scope.
bq. I think this is another case of incomplete JavaDoc.
So I'll wait for the javadoc update - what about ValueMap?
bq. Yes, this should probably be moved to the Sling API. But we did not want to
tie the release of Sightly to an update of the Sling API: The Sling API bundle
cannot alwas be simply updated in a running system unless you want to accept
ripple effects due to extended API in other packages, such as the resource API.
So we start with something which will be added to the Sling API later on and
then we deprecate this stuff again? Maybe we should at least put this in a
separate package so we can deprecate the whole package later on
bq. The RenderContext is created for script evaluation and handed down the
evaluation stack and extensions. I don't think this needs to be exposed as a
service.
I was not refering to making the RenderContext itself a service - I'm refering
to the utility methods in that interface that handle Object traversal and value
conversion - I don't think these methods belong to RenderContext - they can
either be moved to an utility class or service.
Review of the Sightly API
-
Key: SLING-4275
URL: https://issues.apache.org/jira/browse/SLING-4275
Project: Sling
Issue Type: Task
Components: Scripting
Reporter: Carsten Ziegeler
Fix For: Scripting Sightly Engine 1.0.0
I have some comments about the public Sightly API:
1. There are several exceptions, like SightlyException,
RuntimeExtensionException, SightlyUseException - are these really required?
The API does not mention any method/interface throwing such an exception
2. RuntimeExtension and ExtensionInstance - I think we can get rid of the
RuntimeExtension interface and simply pass the RenderContext in
ExtensionInstance#call.
3. The purpose of the Record interface is a little bit unclear to me. In
addition it has a T get(String) method while properties returns a
SetString. I guess the engine supports a Map, so maybe we can get rid of
this interface?
4. ResourceResolution seems to contain methods for getting scripts. Isn't
this some functionalty the existing ServletResolver component provides? Or if
not, shouldn't we move this to the Sling API?
5. Many of the methods in the RenderContext are Object traversal and value
conversion methods. I think this needs to go into a separate service (and
maybe package)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-4233) Change distribution component creation from osgi config factories to osgi component factories
[ https://issues.apache.org/jira/browse/SLING-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marius Petria resolved SLING-4233. -- Resolution: Won't Fix Closing as won't fix as suggested by [~fmeschbe]. We will have a resource provider exposing the osgi configs. Change distribution component creation from osgi config factories to osgi component factories - Key: SLING-4233 URL: https://issues.apache.org/jira/browse/SLING-4233 Project: Sling Issue Type: Improvement Components: Distribution Reporter: Marius Petria Fix For: Content Distribution 0.2.0 In SLING-4154 we introduced the generation of osgi configs from a settings resource tree. This approach has the advantage of using osgi target bindings but has the disadvantage that it stores the settings in two places (in a resource tree e.g. /etc/.../agents and in osgi configs). To overcome this we can generate osgi components directly instead of osgi configs using the ComponentFactory API [1]. That leads to the following setup. 1. Component providers register a component with componentFactory=sling.disitribution.importer.remote 2. All registered factories starting with sling.distribution are picked up by the internal DistributionComponentManager [2] 3. The ResourceBasedComponentFactory [3] listens to content changes in the resource tree and tries to create the corresponding component using the registered factories through [2]. Note that wiring is still done by osgi as the component factories use target reference to bind the needed subcomponents, however the settings are stored in the resource tree. [1] http://www.osgi.org/javadoc/r4v42/org/osgi/service/component/ComponentFactory.html [2] https://github.com/apache/sling/blob/05575da39d80fc29ebd5cd4c2087933c6a97323d/contrib/extensions/distribution/core/src/main/java/org/apache/sling/distribution/component/impl/DistributionComponentManager.java [3] https://github.com/apache/sling/blob/05575da39d80fc29ebd5cd4c2087933c6a97323d/contrib/extensions/distribution/core/src/main/java/org/apache/sling/distribution/component/impl/ResourceBasedDistributionComponentFactory.java -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-4275) Review of the Sightly API
[
https://issues.apache.org/jira/browse/SLING-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264346#comment-14264346
]
Carsten Ziegeler edited comment on SLING-4275 at 1/5/15 8:39 AM:
-
{quote}
* SightlyException is the root exception of all of Sightly.
* SightlyUseException may be thrown by the UseProvider API. Respective JavaDoc
mention is missing
* RuntimeExtensionException may be thrown by the RuntimeExtension API.
Respective JavaDoc is missing
{quote}
Right, but do we really need these different runtime exceptions? Each service
having it's own runtime exception seems like a waste to me, especially as the
caller does not do anything different with such a specific runtime exception
compared to a plain runtime exception.
bq. RuntimeExtension.provide is called once per script evaluation while
ExtensionInstance objects may be called for each occurrence of the extension's
use in the script. As such this is kind of a caching mechanism.
As ExtensionInstance has a single method, I think we could go without this
extra layer of object caching and go with a singleton
bq. The Record interface supports for simplified property access in a much
simpler way than the Map interface would allow. Also Pojo's in use
attributes/statements may implement the Record interface to actually inject
properties into the current evaluation scope.
bq. I think this is another case of incomplete JavaDoc.
So I'll wait for the javadoc update - what about ValueMap?
bq. Yes, this should probably be moved to the Sling API. But we did not want to
tie the release of Sightly to an update of the Sling API: The Sling API bundle
cannot alwas be simply updated in a running system unless you want to accept
ripple effects due to extended API in other packages, such as the resource API.
So we start with something which will be added to the Sling API later on and
then we deprecate this stuff again? Maybe we should at least put this in a
separate package so we can deprecate the whole package later on
bq. The RenderContext is created for script evaluation and handed down the
evaluation stack and extensions. I don't think this needs to be exposed as a
service.
I was not refering to making the RenderContext itself a service - I'm refering
to the utility methods in that interface that handle Object traversal and value
conversion - I don't think these methods belong to RenderContext - they can
either be moved to an utility class or service.
was (Author: cziegeler):
{quote}
* SightlyException is the root exception of all of Sightly.
* SightlyUseException may be thrown by the UseProvider API. Respective JavaDoc
mention is missing
* RuntimeExtensionException may be thrown by the RuntimeExtension API.
Respective JavaDoc is missing
{quote}
Right, but do we really need these different runtime exceptions? Each service
having it's own runtime exception seems like a vaste to me, especially as the
caller does not do anything with such exceptions.
bq. RuntimeExtension.provide is called once per script evaluation while
ExtensionInstance objects may be called for each occurrence of the extension's
use in the script. As such this is kind of a caching mechanism.
As ExtensionInstance has a single method, I think we could go without this
extra layer of object caching and go with a singleton
bq. The Record interface supports for simplified property access in a much
simpler way than the Map interface would allow. Also Pojo's in use
attributes/statements may implement the Record interface to actually inject
properties into the current evaluation scope.
bq. I think this is another case of incomplete JavaDoc.
So I'll wait for the javadoc update - what about ValueMap?
bq. Yes, this should probably be moved to the Sling API. But we did not want to
tie the release of Sightly to an update of the Sling API: The Sling API bundle
cannot alwas be simply updated in a running system unless you want to accept
ripple effects due to extended API in other packages, such as the resource API.
So we start with something which will be added to the Sling API later on and
then we deprecate this stuff again? Maybe we should at least put this in a
separate package so we can deprecate the whole package later on
bq. The RenderContext is created for script evaluation and handed down the
evaluation stack and extensions. I don't think this needs to be exposed as a
service.
I was not refering to making the RenderContext itself a service - I'm refering
to the utility methods in that interface that handle Object traversal and value
conversion - I don't think these methods belong to RenderContext - they can
either be moved to an utility class or service.
Review of the Sightly API
-
Key: SLING-4275
URL: https://issues.apache.org/jira/browse/SLING-4275
Jenkins build is still unstable: sling-oak-it-1.6 #259
See https://builds.apache.org/job/sling-oak-it-1.6/259/
Re: Jenkins build is still unstable: sling-oak-it-1.6 #259
Few test here are failing because required OSGi config are not part of testing Sling app. See mail thread [1] for that. If no proper solution is determine today i would checkin the required config to testing module also to get the test passed Chetan Mehrotra [1] http://markmail.org/thread/xfljme3swaexpcvw On Mon, Jan 5, 2015 at 5:22 PM, Apache Jenkins Server jenk...@builds.apache.org wrote: See https://builds.apache.org/job/sling-oak-it-1.6/259/
[jira] [Commented] (SLING-4275) Review of the Sightly API
[
https://issues.apache.org/jira/browse/SLING-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264529#comment-14264529
]
Radu Cotescu commented on SLING-4275:
-
The {{Record}} interface is also used for the JavaScript Use-API for being able
to translate Java objects into JavaScript objects and back.
Regarding the proposed changes of the {{RenderContext}} I'm not really sure we
should modify it. The {{RenderContext}} class is used by extensions to process
dynamic objects from Sightly templates (therefore providing rendering
assistance) - this also involves sometimes object traversal and value
conversion. Given that extensions could exist outside of the Sightly
implementation from Sling this would turn into a backwards compatibility issue.
Review of the Sightly API
-
Key: SLING-4275
URL: https://issues.apache.org/jira/browse/SLING-4275
Project: Sling
Issue Type: Task
Components: Scripting
Reporter: Carsten Ziegeler
Fix For: Scripting Sightly Engine 1.0.0
I have some comments about the public Sightly API:
1. There are several exceptions, like SightlyException,
RuntimeExtensionException, SightlyUseException - are these really required?
The API does not mention any method/interface throwing such an exception
2. RuntimeExtension and ExtensionInstance - I think we can get rid of the
RuntimeExtension interface and simply pass the RenderContext in
ExtensionInstance#call.
3. The purpose of the Record interface is a little bit unclear to me. In
addition it has a T get(String) method while properties returns a
SetString. I guess the engine supports a Map, so maybe we can get rid of
this interface?
4. ResourceResolution seems to contain methods for getting scripts. Isn't
this some functionalty the existing ServletResolver component provides? Or if
not, shouldn't we move this to the Sling API?
5. Many of the methods in the RenderContext are Object traversal and value
conversion methods. I think this needs to go into a separate service (and
maybe package)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-3230) UpdateUserTest integration test fails with Oak
[ https://issues.apache.org/jira/browse/SLING-3230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264546#comment-14264546 ] Antonio Sanso commented on SLING-3230: -- [~chetanm] lgtm thanks!! UpdateUserTest integration test fails with Oak -- Key: SLING-3230 URL: https://issues.apache.org/jira/browse/SLING-3230 Project: Sling Issue Type: Bug Components: Testing Reporter: Bertrand Delacretaz Priority: Minor Attachments: SLING-3230.patch Two tests fail in UpdateUserTest - the cause for the second looks like SLING-3144. For now, I'll disable those tests with the JackrabbitOnly category. UpdateUserTest.testChangeUserPassword:103 expected:200 but was:500 UpdateUserTest.testChangeUserPasswordAsUserAdminMemberWithoutOldPwd:185 Adding user testUser1383662767745 to group via http://localhost:/system/userManager/group/UserAdmin.update.html expected:200 but was:500 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4282) [Sightly] Fully qualified Use POJOs are not correctly identified in the repository
Radu Cotescu created SLING-4282:
---
Summary: [Sightly] Fully qualified Use POJOs are not correctly
identified in the repository
Key: SLING-4282
URL: https://issues.apache.org/jira/browse/SLING-4282
Project: Sling
Issue Type: Bug
Components: Scripting
Reporter: Radu Cotescu
Fix For: Scripting Sightly Engine 1.0.0
Fully qualified POJOs in {{data-sly-use}} may not be correctly identified in
the JCR repository if the paths where they are stored contain dashes or
underscores due to Java class name restrictions.
The code used for detecting the location of classes that have underscores in
their names should search for repository paths containing both - and _.
Example:
{code:html}
div data-sly-use.obj=apps.my_project.components.Pojo.../div
{code}
could identify the following paths:
# {{/apps/my_project/components/Pojo.java}}
# {{/apps/my-project/components/Pojo.java}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (SLING-3954) i18n filter still not called for error scripts
[
https://issues.apache.org/jira/browse/SLING-3954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler reassigned SLING-3954:
---
Assignee: Carsten Ziegeler
i18n filter still not called for error scripts
--
Key: SLING-3954
URL: https://issues.apache.org/jira/browse/SLING-3954
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: i18n 2.2.6, i18n 2.2.8, i18n 2.2.10
Reporter: Konrad Windszus
Assignee: Carsten Ziegeler
Fix For: i18n 2.2.12
Although this is fixed in the annotation in SLING-2705, the annotation is not
correctly considered when the service xml is being generated. All versions
2.2.6, 2.2.8 and 2.2.10 are affected.
The OSGI-INF/org.apache.sling.i18n.impl.I18NFilter.xml looks like this in all
three versions
{code}
?xml version=1.0 encoding=UTF-8?components
xmlns:scr=http://www.osgi.org/xmlns/scr/v1.2.0;
scr:component name=org.apache.sling.i18n.impl.I18NFilter
implementation class=org.apache.sling.i18n.impl.I18NFilter/
service servicefactory=false
provide interface=javax.servlet.Filter/
/service
property name=service.ranking type=Integer value=-700/
property name=sling.filter.scope value=REQUEST/
property name=pattern value=/.*/
property name=service.description value=Internationalization
Support Filter/
property name=service.vendor value=The Apache Software
Foundation/
property name=service.pid
value=org.apache.sling.i18n.impl.I18NFilter/
reference name=localeResolver
interface=org.apache.sling.i18n.LocaleResolver cardinality=0..1
policy=dynamic bind=bindLocaleResolver unbind=unbindLocaleResolver
policy-option=greedy/
reference name=requestLocaleResolver
interface=org.apache.sling.i18n.RequestLocaleResolver cardinality=0..1
policy=dynamic bind=bindRequestLocaleResolver
unbind=unbindRequestLocaleResolver policy-option=greedy/
reference name=resourceBundleProvider
interface=org.apache.sling.i18n.ResourceBundleProvider cardinality=0..n
policy=dynamic bind=bindResourceBundleProvider
unbind=unbindResourceBundleProvider/
/scr:component
/components
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-3954) i18n filter still not called for error scripts
[
https://issues.apache.org/jira/browse/SLING-3954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264758#comment-14264758
]
Carsten Ziegeler commented on SLING-3954:
-
I've started the release vote for the scr annotations
i18n filter still not called for error scripts
--
Key: SLING-3954
URL: https://issues.apache.org/jira/browse/SLING-3954
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: i18n 2.2.6, i18n 2.2.8, i18n 2.2.10
Reporter: Konrad Windszus
Fix For: i18n 2.2.12
Although this is fixed in the annotation in SLING-2705, the annotation is not
correctly considered when the service xml is being generated. All versions
2.2.6, 2.2.8 and 2.2.10 are affected.
The OSGI-INF/org.apache.sling.i18n.impl.I18NFilter.xml looks like this in all
three versions
{code}
?xml version=1.0 encoding=UTF-8?components
xmlns:scr=http://www.osgi.org/xmlns/scr/v1.2.0;
scr:component name=org.apache.sling.i18n.impl.I18NFilter
implementation class=org.apache.sling.i18n.impl.I18NFilter/
service servicefactory=false
provide interface=javax.servlet.Filter/
/service
property name=service.ranking type=Integer value=-700/
property name=sling.filter.scope value=REQUEST/
property name=pattern value=/.*/
property name=service.description value=Internationalization
Support Filter/
property name=service.vendor value=The Apache Software
Foundation/
property name=service.pid
value=org.apache.sling.i18n.impl.I18NFilter/
reference name=localeResolver
interface=org.apache.sling.i18n.LocaleResolver cardinality=0..1
policy=dynamic bind=bindLocaleResolver unbind=unbindLocaleResolver
policy-option=greedy/
reference name=requestLocaleResolver
interface=org.apache.sling.i18n.RequestLocaleResolver cardinality=0..1
policy=dynamic bind=bindRequestLocaleResolver
unbind=unbindRequestLocaleResolver policy-option=greedy/
reference name=resourceBundleProvider
interface=org.apache.sling.i18n.ResourceBundleProvider cardinality=0..n
policy=dynamic bind=bindResourceBundleProvider
unbind=unbindResourceBundleProvider/
/scr:component
/components
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-3954) i18n filter still not called for error scripts
[
https://issues.apache.org/jira/browse/SLING-3954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-3954:
Fix Version/s: i18n 2.2.12
i18n filter still not called for error scripts
--
Key: SLING-3954
URL: https://issues.apache.org/jira/browse/SLING-3954
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: i18n 2.2.6, i18n 2.2.8, i18n 2.2.10
Reporter: Konrad Windszus
Assignee: Carsten Ziegeler
Fix For: i18n 2.2.12
Although this is fixed in the annotation in SLING-2705, the annotation is not
correctly considered when the service xml is being generated. All versions
2.2.6, 2.2.8 and 2.2.10 are affected.
The OSGI-INF/org.apache.sling.i18n.impl.I18NFilter.xml looks like this in all
three versions
{code}
?xml version=1.0 encoding=UTF-8?components
xmlns:scr=http://www.osgi.org/xmlns/scr/v1.2.0;
scr:component name=org.apache.sling.i18n.impl.I18NFilter
implementation class=org.apache.sling.i18n.impl.I18NFilter/
service servicefactory=false
provide interface=javax.servlet.Filter/
/service
property name=service.ranking type=Integer value=-700/
property name=sling.filter.scope value=REQUEST/
property name=pattern value=/.*/
property name=service.description value=Internationalization
Support Filter/
property name=service.vendor value=The Apache Software
Foundation/
property name=service.pid
value=org.apache.sling.i18n.impl.I18NFilter/
reference name=localeResolver
interface=org.apache.sling.i18n.LocaleResolver cardinality=0..1
policy=dynamic bind=bindLocaleResolver unbind=unbindLocaleResolver
policy-option=greedy/
reference name=requestLocaleResolver
interface=org.apache.sling.i18n.RequestLocaleResolver cardinality=0..1
policy=dynamic bind=bindRequestLocaleResolver
unbind=unbindRequestLocaleResolver policy-option=greedy/
reference name=resourceBundleProvider
interface=org.apache.sling.i18n.ResourceBundleProvider cardinality=0..n
policy=dynamic bind=bindResourceBundleProvider
unbind=unbindResourceBundleProvider/
/scr:component
/components
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SLING-4152) Allow untyped configuration for JSP Compiler
[ https://issues.apache.org/jira/browse/SLING-4152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-4152. - Resolution: Fixed Allow untyped configuration for JSP Compiler Key: SLING-4152 URL: https://issues.apache.org/jira/browse/SLING-4152 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Scripting Java 2.0.12 Reporter: Jörg Hoh Assignee: Carsten Ziegeler Priority: Minor Fix For: Scripting Java 2.0.14 Attachments: patch-sling-4152.diff When providing configuration options as plain strings, I get an exception due to the explicit cast to Boolean in CompilerOptions createOptions() method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4152) Allow untyped configuration for JSP Compiler
[ https://issues.apache.org/jira/browse/SLING-4152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-4152: Fix Version/s: Scripting Java 2.0.14 Allow untyped configuration for JSP Compiler Key: SLING-4152 URL: https://issues.apache.org/jira/browse/SLING-4152 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Scripting Java 2.0.12 Reporter: Jörg Hoh Priority: Minor Fix For: Scripting Java 2.0.14 Attachments: patch-sling-4152.diff When providing configuration options as plain strings, I get an exception due to the explicit cast to Boolean in CompilerOptions createOptions() method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (SLING-4152) Allow untyped configuration for JSP Compiler
[ https://issues.apache.org/jira/browse/SLING-4152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-4152: --- Assignee: Carsten Ziegeler Allow untyped configuration for JSP Compiler Key: SLING-4152 URL: https://issues.apache.org/jira/browse/SLING-4152 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Scripting Java 2.0.12 Reporter: Jörg Hoh Assignee: Carsten Ziegeler Priority: Minor Fix For: Scripting Java 2.0.14 Attachments: patch-sling-4152.diff When providing configuration options as plain strings, I get an exception due to the explicit cast to Boolean in CompilerOptions createOptions() method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4152) Allow untyped configuration for JSP Compiler
[ https://issues.apache.org/jira/browse/SLING-4152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264741#comment-14264741 ] Carsten Ziegeler commented on SLING-4152: - Thanks for your patch; i've applied a corrected version of and also changed all places to use PropertiesUtil Allow untyped configuration for JSP Compiler Key: SLING-4152 URL: https://issues.apache.org/jira/browse/SLING-4152 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: Scripting Java 2.0.12 Reporter: Jörg Hoh Assignee: Carsten Ziegeler Priority: Minor Fix For: Scripting Java 2.0.14 Attachments: patch-sling-4152.diff When providing configuration options as plain strings, I get an exception due to the explicit cast to Boolean in CompilerOptions createOptions() method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-3289) o.a.s.event.it.IgnoreQueueTest causes buildbot timeout sometimes
[ https://issues.apache.org/jira/browse/SLING-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-3289: Fix Version/s: Event 3.4.4 o.a.s.event.it.IgnoreQueueTest causes buildbot timeout sometimes Key: SLING-3289 URL: https://issues.apache.org/jira/browse/SLING-3289 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Event 3.3.0 Reporter: Bertrand Delacretaz Priority: Minor Fix For: Event 3.4.4 Attachments: build42.log http://ci.apache.org/builders/sling-trunk-oak/builds/42 failed with a timeout that's apparently caused by the IgnoreQueueTest integration test. I'll attach the stdio logs, which show this before the timeout: 16.12.2013 05:19:23.193 *WARN* [ Apche Sling JCR Resource Event Queue Processor for path '/'] org.apache.felix.eventadmin EventAdmin: Blacklisting ServiceReference [[org.apache.sling.event.jobs.JobManager, org.osgi.service.event.EventHandler, org.apache.sling.discovery.TopologyEventListener, java.lang.Runnable] | Bundle(org.apache.sling.event [66])] due to timeout! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-3289) o.a.s.event.it.IgnoreQueueTest causes buildbot timeout sometimes
[ https://issues.apache.org/jira/browse/SLING-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3289. - Resolution: Fixed Assignee: Carsten Ziegeler We fixed that at some point, therefore closing this issue o.a.s.event.it.IgnoreQueueTest causes buildbot timeout sometimes Key: SLING-3289 URL: https://issues.apache.org/jira/browse/SLING-3289 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Event 3.3.0 Reporter: Bertrand Delacretaz Assignee: Carsten Ziegeler Priority: Minor Fix For: Event 3.4.4 Attachments: build42.log http://ci.apache.org/builders/sling-trunk-oak/builds/42 failed with a timeout that's apparently caused by the IgnoreQueueTest integration test. I'll attach the stdio logs, which show this before the timeout: 16.12.2013 05:19:23.193 *WARN* [ Apche Sling JCR Resource Event Queue Processor for path '/'] org.apache.felix.eventadmin EventAdmin: Blacklisting ServiceReference [[org.apache.sling.event.jobs.JobManager, org.osgi.service.event.EventHandler, org.apache.sling.discovery.TopologyEventListener, java.lang.Runnable] | Bundle(org.apache.sling.event [66])] due to timeout! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-3202) org.apache.sling.event.it.ClassloadingTest deadlock
[ https://issues.apache.org/jira/browse/SLING-3202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-3202: Fix Version/s: Event 3.4.4 org.apache.sling.event.it.ClassloadingTest deadlock Key: SLING-3202 URL: https://issues.apache.org/jira/browse/SLING-3202 Project: Sling Issue Type: Bug Components: Extensions Environment: java version 1.6.0_51 macosx 10.7.5 Reporter: Bertrand Delacretaz Priority: Minor Fix For: Event 3.4.4 Attachments: SLING-3194-stacktrace.txt, testlog.txt This doesn't happen all the time but I just got a deadlock while running a full Sling build of svn revision 1534947 I'll attach a stack trace + console log. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-3202) org.apache.sling.event.it.ClassloadingTest deadlock
[ https://issues.apache.org/jira/browse/SLING-3202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3202. - Resolution: Fixed We haven't seen this for a long time, therefore setting to fixed org.apache.sling.event.it.ClassloadingTest deadlock Key: SLING-3202 URL: https://issues.apache.org/jira/browse/SLING-3202 Project: Sling Issue Type: Bug Components: Extensions Environment: java version 1.6.0_51 macosx 10.7.5 Reporter: Bertrand Delacretaz Assignee: Carsten Ziegeler Priority: Minor Fix For: Event 3.4.4 Attachments: SLING-3194-stacktrace.txt, testlog.txt This doesn't happen all the time but I just got a deadlock while running a full Sling build of svn revision 1534947 I'll attach a stack trace + console log. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SLING-3202) org.apache.sling.event.it.ClassloadingTest deadlock
[ https://issues.apache.org/jira/browse/SLING-3202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-3202. --- org.apache.sling.event.it.ClassloadingTest deadlock Key: SLING-3202 URL: https://issues.apache.org/jira/browse/SLING-3202 Project: Sling Issue Type: Bug Components: Extensions Environment: java version 1.6.0_51 macosx 10.7.5 Reporter: Bertrand Delacretaz Assignee: Carsten Ziegeler Priority: Minor Fix For: Event 3.4.4 Attachments: SLING-3194-stacktrace.txt, testlog.txt This doesn't happen all the time but I just got a deadlock while running a full Sling build of svn revision 1534947 I'll attach a stack trace + console log. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Sling JCR Resource Security 1.0.0
Am 05.01.15 um 16:57 schrieb Carsten Ziegeler: Hi, it's time to make a first release of this module: https://issues.apache.org/jira/browse/SLING-3438 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1158/ 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 1158 /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. Regards Carsten +1 Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Jenkins build is back to stable : sling-trunk-1.7 #1281
See https://builds.apache.org/job/sling-trunk-1.7/1281/changes
Jenkins build is still unstable: sling-oak-it-1.6 #262
See https://builds.apache.org/job/sling-oak-it-1.6/262/
[jira] [Resolved] (SLING-3501) Unexpected behaviour when using multiple tags in the web console to run checks
[ https://issues.apache.org/jira/browse/SLING-3501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz resolved SLING-3501. Resolution: Fixed Thanks for your contribution! I have committed it in revision 1649574 with a minor tweak (webconsole label) in revision 1649576. I don't think there were any tests for the AND vs OR selection, so I added a few in revision 1649583 Unexpected behaviour when using multiple tags in the web console to run checks -- Key: SLING-3501 URL: https://issues.apache.org/jira/browse/SLING-3501 Project: Sling Issue Type: Bug Components: Health Check Reporter: Georg Henzler Assignee: Bertrand Delacretaz Attachments: SLING-3501-executor-options2.patch Multiple tags (e.g. category1,category2) are connected with a logical AND at the moment, that means for the given example only HCs with both category tags would be run. From a user's point of view this behaviour is not intuitive (IMHO, also see Björn's comment in the sling-users list [1]). Using the tags category1,category2 should rather cause all checks of both categories to be run (union instead of intersection). The problem is evident for both the web console [2] and when configuring CompositeHealthChecks (both use HealthCheckFilter). [1] http://apache-sling.73963.n3.nabble.com/Healthcheck-Unexpected-behavior-with-tags-td4032090.html [2] http://localhost:4502/system/console/healthcheck -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-3057) Ghosted reference to dependent bundle after .java script compilation prevents complete uninstallation
[ https://issues.apache.org/jira/browse/SLING-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14265307#comment-14265307 ] Barett McGavock commented on SLING-3057: Yes, we are uninstalling and reinstalling the bundles. Ghosted reference to dependent bundle after .java script compilation prevents complete uninstallation - Key: SLING-3057 URL: https://issues.apache.org/jira/browse/SLING-3057 Project: Sling Issue Type: Bug Components: Scripting Affects Versions: Scripting Java 2.0.6 Environment: RHEL 6, Adobe CQ 5.6.1 Reporter: Mark Adamcin It appears that a lock is established on the cache directory of any bundle which is imported by a compiled .java script that prevents complete uninstallation of the dependent bundle, even after reinstallation of the bundle. The reinstalled bundle creates a new distinct cache folder under launchpad/felix, while the uninstalled cache folder remains write protected. Subsequent recompilation of the .java script after reinstallation of the bundle fails due to missing .class files, with the message: some class resolves to a package.. Restarting the Dynamic ClassLoader Support bundle or the Scripting Java bundle fails to force a recompilation using the newly reinstalled bundle, however a complete application restart will force the old cache folder to be garbage collected, and the .java script will compile correctly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build became unstable: sling-trunk-1.6 #2901
See https://builds.apache.org/job/sling-trunk-1.6/2901/changes
[jira] [Comment Edited] (SLING-4275) Review of the Sightly API
[ https://issues.apache.org/jira/browse/SLING-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264684#comment-14264684 ] Carsten Ziegeler edited comment on SLING-4275 at 1/5/15 3:45 PM: - We could pass in two arguments :) And with the same argument we could add a bunch of utility methods to the RenderContext just because they are useful for extensions. What about adding a getConverter() (or maybe a better name) method to RenderContext and move all the toXXX into that one? This avoids bloating the RenderContext with all these methdods. Or have a ConversionUtil with static methods (similar to the PropertiesUtil we have for configuration handling)? I'm also wondering why there is a generic toNumber method and not toInteger, or toFloat? And what do you think about removing the RuntimeExtension interface? was (Author: cziegeler): We could pass in two arguments :) And with the same argument we could add a bunch of utility methods to the RenderContext just because they are useful for extensions. What about adding a getConverter() (or maybe a better name) method to RenderContext and move all the toXXX into that one? This avoids bloating the RenderContext with all these methdods. I'm also wondering why there is a generic toNumber method and not toInteger, or toFloat? And what do you think about removing the RuntimeExtension interface? Review of the Sightly API - Key: SLING-4275 URL: https://issues.apache.org/jira/browse/SLING-4275 Project: Sling Issue Type: Task Components: Scripting Reporter: Carsten Ziegeler Fix For: Scripting Sightly Engine 1.0.0 I have some comments about the public Sightly API: 1. There are several exceptions, like SightlyException, RuntimeExtensionException, SightlyUseException - are these really required? The API does not mention any method/interface throwing such an exception 2. RuntimeExtension and ExtensionInstance - I think we can get rid of the RuntimeExtension interface and simply pass the RenderContext in ExtensionInstance#call. 3. The purpose of the Record interface is a little bit unclear to me. In addition it has a T get(String) method while properties returns a SetString. I guess the engine supports a Map, so maybe we can get rid of this interface? 4. ResourceResolution seems to contain methods for getting scripts. Isn't this some functionalty the existing ServletResolver component provides? Or if not, shouldn't we move this to the Sling API? 5. Many of the methods in the RenderContext are Object traversal and value conversion methods. I think this needs to go into a separate service (and maybe package) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4275) Review of the Sightly API
[ https://issues.apache.org/jira/browse/SLING-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264684#comment-14264684 ] Carsten Ziegeler commented on SLING-4275: - We could pass in two arguments :) And with the same argument we could add a bunch of utility methods to the RenderContext just because they are useful for extensions. What about adding a getConverter() (or maybe a better name) method to RenderContext and move all the toXXX into that one? This avoids bloating the RenderContext with all these methdods. I'm also wondering why there is a generic toNumber method and not toInteger, or toFloat? And what do you think about removing the RuntimeExtension interface? Review of the Sightly API - Key: SLING-4275 URL: https://issues.apache.org/jira/browse/SLING-4275 Project: Sling Issue Type: Task Components: Scripting Reporter: Carsten Ziegeler Fix For: Scripting Sightly Engine 1.0.0 I have some comments about the public Sightly API: 1. There are several exceptions, like SightlyException, RuntimeExtensionException, SightlyUseException - are these really required? The API does not mention any method/interface throwing such an exception 2. RuntimeExtension and ExtensionInstance - I think we can get rid of the RuntimeExtension interface and simply pass the RenderContext in ExtensionInstance#call. 3. The purpose of the Record interface is a little bit unclear to me. In addition it has a T get(String) method while properties returns a SetString. I guess the engine supports a Map, so maybe we can get rid of this interface? 4. ResourceResolution seems to contain methods for getting scripts. Isn't this some functionalty the existing ServletResolver component provides? Or if not, shouldn't we move this to the Sling API? 5. Many of the methods in the RenderContext are Object traversal and value conversion methods. I think this needs to go into a separate service (and maybe package) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build is still unstable: sling-oak-it-1.6 #261
See https://builds.apache.org/job/sling-oak-it-1.6/261/
[VOTE] Release Apache Sling JCR Resource Security 1.0.0
Hi, it's time to make a first release of this module: https://issues.apache.org/jira/browse/SLING-3438 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1158/ 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 1158 /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. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
