Hudson build is unstable: sling-trunk-1.5 » Apache Sling Launchpad Testing #1039
See https://hudson.apache.org/hudson/job/sling-trunk-1.5/org.apache.sling$org.apache.sling.launchpad.testing/1039/
Hudson build is unstable: sling-trunk-1.5 » Apache Sling Launchpad Testing WAR version #1039
See https://hudson.apache.org/hudson/job/sling-trunk-1.5/org.apache.sling$org.apache.sling.launchpad.testing-war/1039/
Hudson build is unstable: sling-trunk-1.5 #1039
See https://hudson.apache.org/hudson/job/sling-trunk-1.5/1039/changes
Hudson build is back to normal : sling-trunk-1.6 » Apache Sling Integration Tests #726
See https://hudson.apache.org/hudson/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.integration-tests/726/
Hudson build is unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing #726
See https://hudson.apache.org/hudson/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/726/
Hudson build is unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing WAR version #726
See https://hudson.apache.org/hudson/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing-war/726/
Hudson build is unstable: sling-trunk-1.6 #726
See https://hudson.apache.org/hudson/job/sling-trunk-1.6/726/changes
[jira] Created: (SLING-1949) Improve removal of bundles if the bundle is installed more than once
Improve removal of bundles if the bundle is installed more than once Key: SLING-1949 URL: https://issues.apache.org/jira/browse/SLING-1949 Project: Sling Issue Type: Bug Components: Installer Affects Versions: Installer Core 3.1.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Priority: Minor Fix For: Installer Core 3.1.2 If a bundle is removed through a provider but is installed more than once, currently the first one with the same symbolic name is compared with the bundle to be uninstalled. If the version does not match, nothing happens. If a bundle with a symbolic name is installed once, this is no problem - but as soon as a bundle with the same symbolic name is installed more than once, the wrong bundle can be used for the comparison. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1949) Improve removal of bundles if the bundle is installed more than once
[ https://issues.apache.org/jira/browse/SLING-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1949. - Resolution: Fixed Now searching an exact match (symbolic name and version) when uninstalling; for installing now the bundle with the same symbolic name and highest version is used. Revision 1062180 Improve removal of bundles if the bundle is installed more than once Key: SLING-1949 URL: https://issues.apache.org/jira/browse/SLING-1949 Project: Sling Issue Type: Bug Components: Installer Affects Versions: Installer Core 3.1.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Priority: Minor Fix For: Installer Core 3.1.2 If a bundle is removed through a provider but is installed more than once, currently the first one with the same symbolic name is compared with the bundle to be uninstalled. If the version does not match, nothing happens. If a bundle with a symbolic name is installed once, this is no problem - but as soon as a bundle with the same symbolic name is installed more than once, the wrong bundle can be used for the comparison. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1950) Parameters are not removed from symbolic name
Parameters are not removed from symbolic name - Key: SLING-1950 URL: https://issues.apache.org/jira/browse/SLING-1950 Project: Sling Issue Type: Bug Affects Versions: Installer Core 3.1.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Installer Core 3.1.2 If the symbolic name header contains parameters, these are not removed for further processing. Therefore searching the bundle with the symbolic name always results in a bundle not found. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] New Releases for Sling 6
Hi, can anyone else please have a look at the release? Currently we have only two votes! Thanks Carsten Carsten Ziegeler wrote Hi, this is another set of new releases for SLING-6. I think we're nearly through now... Most of these releases are minor bug fix releases. But I think it's better to release early and often :) This vote is about the release of: - Apache Sling Commons Compiler 2.0.2 [1] - Apache Sling JCR Compiler 2.0.2 [2] - Apache Sling Commons Log 2.1.2 [3] - Apache Sling Event 3.0.0 [4] - Apache Sling Scripting JSP 2.0.14 [5] - Apache Sling Installer Core 3.1.0 [6] - Apache Sling JCR Installer 3.0.2 [7] We solved some important issues in each release to get SLING-6 going: [1] https://issues.apache.org/jira/browse/SLING/fixforversion/12315997 [2] https://issues.apache.org/jira/browse/SLING/fixforversion/12316007 [3] https://issues.apache.org/jira/browse/SLING/fixforversion/12316000 [4] https://issues.apache.org/jira/browse/SLING/fixforversion/12315369 [5] https://issues.apache.org/jira/browse/SLING/fixforversion/12316005 [6] https://issues.apache.org/jira/browse/SLING/fixforversion/12315352 [7] https://issues.apache.org/jira/browse/SLING/fixforversion/12315353 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-043/ 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 043 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] Resolved: (SLING-1950) Parameters are not removed from symbolic name
[ https://issues.apache.org/jira/browse/SLING-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1950. - Resolution: Fixed Fixed in revision 1062193 Parameters are not removed from symbolic name - Key: SLING-1950 URL: https://issues.apache.org/jira/browse/SLING-1950 Project: Sling Issue Type: Bug Affects Versions: Installer Core 3.1.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Installer Core 3.1.2 If the symbolic name header contains parameters, these are not removed for further processing. Therefore searching the bundle with the symbolic name always results in a bundle not found. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Hudson build is still unstable: sling-trunk-1.5 » Apache Sling Launchpad Testing WAR version #1040
See https://hudson.apache.org/hudson/job/sling-trunk-1.5/org.apache.sling$org.apache.sling.launchpad.testing-war/1040/
Hudson build is still unstable: sling-trunk-1.5 » Apache Sling Launchpad Testing #1040
See https://hudson.apache.org/hudson/job/sling-trunk-1.5/org.apache.sling$org.apache.sling.launchpad.testing/1040/
Hudson build is still unstable: sling-trunk-1.5 #1040
See https://hudson.apache.org/hudson/job/sling-trunk-1.5/changes
[jira] Updated: (SLING-1946) Transformer should only be invoked once on an untransformed resource
[ https://issues.apache.org/jira/browse/SLING-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-1946: Component/s: Installer Transformer should only be invoked once on an untransformed resource Key: SLING-1946 URL: https://issues.apache.org/jira/browse/SLING-1946 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: Installer Core 3.1.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Installer Core 3.1.2 If a transformer has seen a resource, it should not be invoked again on this resource regardless if the transformation has been successdful or not -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1950) Parameters are not removed from symbolic name
[ https://issues.apache.org/jira/browse/SLING-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-1950: Component/s: Installer Parameters are not removed from symbolic name - Key: SLING-1950 URL: https://issues.apache.org/jira/browse/SLING-1950 Project: Sling Issue Type: Bug Components: Installer Affects Versions: Installer Core 3.1.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Installer Core 3.1.2 If the symbolic name header contains parameters, these are not removed for further processing. Therefore searching the bundle with the symbolic name always results in a bundle not found. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1946) Transformer should only be invoked once on an untransformed resource
[ https://issues.apache.org/jira/browse/SLING-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1946. - Resolution: Fixed The transformer service is identified by the service id - a transformer with a service id is only invoked once on an untransformed resource Fixed in revision 1062196 Transformer should only be invoked once on an untransformed resource Key: SLING-1946 URL: https://issues.apache.org/jira/browse/SLING-1946 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: Installer Core 3.1.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Installer Core 3.1.2 If a transformer has seen a resource, it should not be invoked again on this resource regardless if the transformation has been successdful or not -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Hudson build is still unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing WAR version #727
See https://hudson.apache.org/hudson/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing-war/727/
Hudson build is still unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing #727
See https://hudson.apache.org/hudson/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/727/
Hudson build is still unstable: sling-trunk-1.6 #727
See https://hudson.apache.org/hudson/job/sling-trunk-1.6/changes
Hudson build is still unstable: sling-trunk-1.5 » Apache Sling Launchpad Testing #1041
See https://hudson.apache.org/hudson/job/sling-trunk-1.5/org.apache.sling$org.apache.sling.launchpad.testing/1041/
Hudson build is still unstable: sling-trunk-1.5 #1041
See https://hudson.apache.org/hudson/job/sling-trunk-1.5/changes
Re: Extended Java APIs (javax.xml, e.a.)
+1 On Wed, Jan 19, 2011 at 9:50 AM, Felix Meschberger fmesc...@adobe.comwrote: Hi all, We currently add a whole bunch of Java Extension APIs in the javax.* arena to the export list of the system bundle by virtue of actually providing in the framework, what is provided in the JDK. While we (at Adobe) are now confronted with real-life use of such API (javax.xml, etc.) we run in to a number of issues, like class loading but also incompleteness of the API packages provided by the platform. I am thus considering the following as a potential idea: * We remove the extension API (mostly around XML and DOM stuff) from the sling.properties file and thus do not by default provide it in the framework any longer * As a replacement we create a system extension fragment bundle which re-adds these packages * For more demanding applications the fragment bundle can be replaced with a bundle containing and exporting the full API packages -- thus effectively hiding what is provided by platform. WDYT ? Regards Felix
[VOTE] Release Apache Sling Scripting Core version 2.0.16
Hi, We solved 2 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12315447 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-067/ 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 067 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Justin
Re: svn commit: r1062229 - /sling/trunk/launchpad/builder/src/main/bundles/list.xml
I'm still uncertain that this is appropriate to include in the Sling 6 release, but it has to stay in launchpad/builder/src/main/bundles/list.xml for the time being because there are integration tests which depend upon it. I guess the existence of integration tests is a good sign that this bundle should in fact be included in the release... Justin On Sat, Jan 22, 2011 at 1:56 PM, jus...@apache.org wrote: Author: justin Date: Sat Jan 22 18:56:37 2011 New Revision: 1062229 URL: http://svn.apache.org/viewvc?rev=1062229view=rev Log: restoring groovy extension to launchpad bundle list to fix failing tests Modified: sling/trunk/launchpad/builder/src/main/bundles/list.xml Modified: sling/trunk/launchpad/builder/src/main/bundles/list.xml URL: http://svn.apache.org/viewvc/sling/trunk/launchpad/builder/src/main/bundles/list.xml?rev=1062229r1=1062228r2=1062229view=diff == --- sling/trunk/launchpad/builder/src/main/bundles/list.xml (original) +++ sling/trunk/launchpad/builder/src/main/bundles/list.xml Sat Jan 22 18:56:37 2011 @@ -258,6 +258,11 @@ /bundle bundle groupIdorg.apache.sling/groupId +artifactIdorg.apache.sling.extensions.groovy/artifactId +version1.0.0-SNAPSHOT/version +/bundle +bundle +groupIdorg.apache.sling/groupId artifactIdorg.apache.sling.extensions.explorer/artifactId version1.0.0/version /bundle
Hudson build is still unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing #728
See https://hudson.apache.org/hudson/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/728/
Hudson build is still unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing WAR version #728
See https://hudson.apache.org/hudson/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing-war/728/
Hudson build is still unstable: sling-trunk-1.6 #728
See https://hudson.apache.org/hudson/job/sling-trunk-1.6/changes
Re: [VOTE] Release Apache Sling Scripting Core version 2.0.16
Here's my +1 On Sat, Jan 22, 2011 at 2:12 PM, Justin Edelson jus...@justinedelson.comwrote: Hi, We solved 2 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12315447 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-067/ 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 067 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Justin
[jira] Resolved: (SLING-1940) selector form submits to the wrong path when used in a non-root servlet context
[
https://issues.apache.org/jira/browse/SLING-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson resolved SLING-1940.
---
Resolution: Fixed
Fix Version/s: Auth Core 1.0.6
after some consideration, I changed my mind and now agree with Carsten that we
should treat the resource query param as an absolute path. Thus, in r1062243,
changed AbstractAuthenticationFormServlet to not include the servlet context
path in the requestContextPath substitution variable.
selector form submits to the wrong path when used in a non-root servlet
context
---
Key: SLING-1940
URL: https://issues.apache.org/jira/browse/SLING-1940
Project: Sling
Issue Type: Bug
Components: Authentication
Reporter: Justin Edelson
Assignee: Justin Edelson
Fix For: Auth Core 1.0.6
If you run Sling on a non-root servlet context go to the login page (e.g.
http://localhost:8080/org.apache.sling.launchpad.testing-war-6-SNAPSHOT/system/sling/login.html),
the login servlet redirects to a login form with a query parameter called
resource set to the servlet context path (e.g.
http://localhost:8080/org.apache.sling.launchpad.testing-war-6-SNAPSHOT/system/sling/selector/login?resource=%2Forg.apache.sling.launchpad.testing-war-6-SNAPSHOT)
When the form is created, the HTML form submission path (i.e. the form
action) contains the servlet context path *twice*, e.g.
action=/org.apache.sling.launchpad.testing-war-6-SNAPSHOT/org.apache.sling.launchpad.testing-war-6-SNAPSHOT/j_security_check
The reason for this is that
org.apache.sling.auth.core.spi.AbstractAuthenticationFormServlet.getContextPath()
concatenates the servlet context path and the resource query param:
StringBuilder b = new StringBuilder();
b.append(request.getContextPath());
String resource = getResource(request);
int query = resource.indexOf('?');
if (query 0) {
b.append(resource.substring(0, query));
} else {
b.append(resource);
}
Obviously, we should only add the servlet context path once, either in the
resource query param OR AbstractAuthenticationFormServlet.getContextPath().
My inclination is to do the former, i.e. the default value of the resource
query param is /, not the servlet context path.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
how to best express dependency from auth.selector to auth.core
Based on the changes in SLING-1933, auth.selector 1.0.4 (the next release) will depend upon auth.core 1.0.6. auth.selector now depends upon a new substitution variable which only exists in auth.core 1.0.6 (and higher). This change (adding the substitution variable) wasn't an API change in the way I normally think of an API change, but I think it is important to capture this dependency somewhere. It this just as simple as upgrading the export version of org.apache.sling.auth.core.spi to 1.0.4 and specifying this as the import version in auth.selector? Is there some better way of expressing this? Thanks, Justin
Hudson build is back to stable : sling-trunk-1.5 » Apache Sling Launchpad Testing WAR version #1042
See https://hudson.apache.org/hudson/job/sling-trunk-1.5/org.apache.sling$org.apache.sling.launchpad.testing-war/1042/
Hudson build is back to stable : sling-trunk-1.5 » Apache Sling Launchpad Testing #1042
See https://hudson.apache.org/hudson/job/sling-trunk-1.5/org.apache.sling$org.apache.sling.launchpad.testing/1042/
Hudson build is back to stable : sling-trunk-1.5 #1042
See https://hudson.apache.org/hudson/job/sling-trunk-1.5/1042/changes
Hudson build is back to stable : sling-trunk-1.6 » Apache Sling Launchpad Testing WAR version #729
See https://hudson.apache.org/hudson/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing-war/729/
Hudson build is back to stable : sling-trunk-1.6 » Apache Sling Launchpad Testing #729
See https://hudson.apache.org/hudson/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/729/
