[jira] Commented: (SLING-1181) Scripts loaded by Bundle Resource Provider are not found in script resolution
[
https://issues.apache.org/jira/browse/SLING-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776473#action_12776473
]
Ian Boston commented on SLING-1181:
---
When Install the bundle it does not install the file.
(http://localhost:8080/apps.tidy.5.json does not show any trace of the Servlet)
When I upload the esp file using webdav, it is reported by the resolver, eg
curl -XMKCOL http://admin:ad...@localhost:8080/apps/testtype
cat << EOF > sel.esp
This is the node at <%=currentNode.path%>
EOF
curl -F"sel.e...@sel.esp;type=text/plain"
http://admin:ad...@localhost:8080/apps/testtype
curl http://localhost:8080/apps/testtype.tidy.2.json
curl -Fsling:resourceType=testtype http://admin:ad...@localhost:8080/testnode
curl http://localhost:8080/testnode.json
curl http://localhost:8080/testnode.sel
curl http://localhost:8080/testnode.sel.html
The last 3 lines give
x43543-2:tmp ieb$ curl http://localhost:8080/testnode.json
{"sling:resourceType":"testtype","jcr:primaryType":"nt:unstructured"}x43543-2:tmp
ieb$
x43543-2:tmp ieb$ curl http://localhost:8080/testnode.sel
This is the node at /testnode
x43543-2:tmp ieb$ curl http://localhost:8080/testnode.sel.html
This is the node at /testnode
x43543-2:tmp ieb$
So, AFAICT, the resolution of Servlets under apps is working correctly,
What does not appear to be working is the loading of content, so a
mvn clean install
mvn org.apache.sling:maven-sling-plugin:install
generates
11.11.2009 14:50:06.319 *INFO* [FelixDispatchQueue]
org.apache.sling.bundleresource.impl Service [Provider of bundle based
resources,94] ServiceEvent UNREGISTERING
11.11.2009 14:50:06.321 *INFO* [FelixDispatchQueue]
SlingBundleResourceTestBundle BundleEvent STOPPED
11.11.2009 14:50:06.321 *INFO* [FelixDispatchQueue]
SlingBundleResourceTestBundle BundleEvent UNRESOLVED
11.11.2009 14:50:06.321 *INFO* [FelixDispatchQueue]
SlingBundleResourceTestBundle BundleEvent UPDATED
11.11.2009 14:50:06.321 *INFO* [FelixDispatchQueue] org.apache.felix.framework
FrameworkEvent PACKAGES REFRESHED
11.11.2009 14:50:06.321 *INFO* [FelixDispatchQueue]
SlingBundleResourceTestBundle BundleEvent RESOLVED
11.11.2009 14:50:06.325 *INFO* [FelixDispatchQueue]
org.apache.sling.bundleresource.impl Service [Provider of bundle based
resources,95] ServiceEvent REGISTERED
11.11.2009 14:50:06.325 *INFO* [FelixDispatchQueue]
SlingBundleResourceTestBundle BundleEvent STARTED
11.11.2009 14:50:08.326 *INFO* [FelixDispatchQueue]
org.apache.sling.bundleresource.impl Service [Provider of bundle based
resources,95] ServiceEvent UNREGISTERING
11.11.2009 14:50:08.326 *INFO* [FelixDispatchQueue]
SlingBundleResourceTestBundle BundleEvent STOPPED
11.11.2009 14:50:08.326 *INFO* [FelixDispatchQueue]
SlingBundleResourceTestBundle BundleEvent RESOLVED
11.11.2009 14:50:08.329 *INFO* [FelixDispatchQueue]
org.apache.sling.bundleresource.impl Service [Provider of bundle based
resources,96] ServiceEvent REGISTERED
11.11.2009 14:50:08.329 *INFO* [FelixDispatchQueue]
SlingBundleResourceTestBundle BundleEvent STARTED
11.11.2009 14:50:08.330 *INFO* [FelixDispatchQueue] org.apache.felix.framework
FrameworkEvent PACKAGES REFRESHED
Indicating that the bundle content didnt get installed.
I will investigate further.
> Scripts loaded by Bundle Resource Provider are not found in script resolution
> -
>
> Key: SLING-1181
> URL: https://issues.apache.org/jira/browse/SLING-1181
> Project: Sling
> Issue Type: Bug
>Reporter: Vidar S. Ramdal
>Assignee: Ian Boston
>Priority: Critical
> Attachments: SLING-1181-test-bundle-source-and-jar.zip
>
>
> When a script file is loaded as a bundle resource (using
> Sling-Bundle-Resources directive), it is not picked up during script
> resolution.
> The bundle resource IS listed at /system/console/bundleresources, and the
> script source is available at its URL under /apps.
> I can reproduce this problem using the latest trunk build (rev #834413), but
> not in builds prior to rev#825679. I will try to narrow it down, to find the
> actual change causing this.
> To reproduce:
> 1. Run a fresh Sling build
> 2. Upload a bundle with a
> /apps directive, containing
> a file at /apps/someResourceType/bundleresource.esp. The script file could
> contain the code:
> "BundleResource script, <%=currentNode.path%>"
> 3. Using WebDAV, create a script at /apps/someResourceType/webdav.esp. The
> script file could contain the code:
>"WebDAV-uploaded script, <%=currentNode.path%>"
> 4. Create a node /test, with sling:resourceType=someResourceType
> 5. Browse to http://localhost:8080/apps/someResourceType/bundleresource.esp,
> and assert that the source code of the script file is displayed
> 6. Browse to http://localhost:8080/system/console/bundleresour
[jira] Commented: (SLING-1181) Scripts loaded by Bundle Resource Provider are not found in script resolution
[
https://issues.apache.org/jira/browse/SLING-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776475#action_12776475
]
Ian Boston commented on SLING-1181:
---
At the moment, I cant reproduce the problem in the way its been reported,
although I can reproduce a problem with the Test Bundle being supplied.
I also get a 403 trying http://localhost:8080/testnode.webdav but not
http://localhost:8080/testnode.json (in fact I get a 403 for anything ending in
webdav)
x43543-2:tmp ieb$ curl http://admin:ad...@localhost:8080/testnode.webdav
403 Forbidden
Forbidden (403)
The requested URL /testnode.webdav resulted in an error in
org.apache.sling.servlets.get.DefaultGetServlet.
ApacheSling/2.0 (Java HotSpot(TM) Client VM 1.5.0_20; Mac OS X 10.5.8
i386)
x43543-2:tmp ieb$ curl http://admin:ad...@localhost:8080/testnode.json
{"sling:resourceType":"testtype","jcr:primaryType":"nt:unstructured"}x43543-2:tmp
ieb$
x43543-2:tmp ieb$
> Scripts loaded by Bundle Resource Provider are not found in script resolution
> -
>
> Key: SLING-1181
> URL: https://issues.apache.org/jira/browse/SLING-1181
> Project: Sling
> Issue Type: Bug
>Reporter: Vidar S. Ramdal
>Assignee: Ian Boston
>Priority: Critical
> Attachments: SLING-1181-test-bundle-source-and-jar.zip
>
>
> When a script file is loaded as a bundle resource (using
> Sling-Bundle-Resources directive), it is not picked up during script
> resolution.
> The bundle resource IS listed at /system/console/bundleresources, and the
> script source is available at its URL under /apps.
> I can reproduce this problem using the latest trunk build (rev #834413), but
> not in builds prior to rev#825679. I will try to narrow it down, to find the
> actual change causing this.
> To reproduce:
> 1. Run a fresh Sling build
> 2. Upload a bundle with a
> /apps directive, containing
> a file at /apps/someResourceType/bundleresource.esp. The script file could
> contain the code:
> "BundleResource script, <%=currentNode.path%>"
> 3. Using WebDAV, create a script at /apps/someResourceType/webdav.esp. The
> script file could contain the code:
>"WebDAV-uploaded script, <%=currentNode.path%>"
> 4. Create a node /test, with sling:resourceType=someResourceType
> 5. Browse to http://localhost:8080/apps/someResourceType/bundleresource.esp,
> and assert that the source code of the script file is displayed
> 6. Browse to http://localhost:8080/system/console/bundleresources, and assert
> that the /apps resource is listed
> 7. Browse to http://localhost:8080/test.webdav, and assert that the
> WebDAV-uploaded script is used to render the node (displaying
> "WebDAV-uploaded script, /test")
> 8. Browse to http://localhost:8080/test.bundleresource
> Expected result:
> - The bundleresource-provided script is used to render the node, displaying
> "BundleResource script, /test"
> Actual result:
> - 403 Forbidden
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1181) Scripts loaded by Bundle Resource Provider are not found in script resolution
[
https://issues.apache.org/jira/browse/SLING-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776480#action_12776480
]
Ian Boston commented on SLING-1181:
---
x43543-2:tmp ieb$ curl
http://localhost:8080/apps/someResourceType/bundleresource.esp
This is the node at <%=currentNode.path%>x43543-2:tmp ieb$
x43543-2:tmp ieb$
So yes a direct url to the resource resolves, but it does not appear on the
list, indicating that registration is not complete.
}x43543-2:tmp ieb$ curl http://localhost:8080/apps.tidy.5.json
{
"jcr:created": "Wed Nov 11 2009 14:00:23 GMT+",
"jcr:primaryType": "sling:Folder",
"sling": {
"jcr:created": "Wed Nov 11 2009 14:00:23 GMT+",
"jcr:primaryType": "sling:Folder",
}
},
"someResourceType": {
},
}
>From this it looks like the BundleResourceProvider is partially registered and
>has not registered the full path to the resource, or is not listing its
>children (the resolution of ServletResources relies on the listing of children
>at each layer)
This is confirmed by browsing with a webdav client that does not see
someResourceType or bundleresource.esp
I think I have a better idea where the problem is now.
> Scripts loaded by Bundle Resource Provider are not found in script resolution
> -
>
> Key: SLING-1181
> URL: https://issues.apache.org/jira/browse/SLING-1181
> Project: Sling
> Issue Type: Bug
>Reporter: Vidar S. Ramdal
>Assignee: Ian Boston
>Priority: Critical
> Attachments: SLING-1181-test-bundle-source-and-jar.zip
>
>
> When a script file is loaded as a bundle resource (using
> Sling-Bundle-Resources directive), it is not picked up during script
> resolution.
> The bundle resource IS listed at /system/console/bundleresources, and the
> script source is available at its URL under /apps.
> I can reproduce this problem using the latest trunk build (rev #834413), but
> not in builds prior to rev#825679. I will try to narrow it down, to find the
> actual change causing this.
> To reproduce:
> 1. Run a fresh Sling build
> 2. Upload a bundle with a
> /apps directive, containing
> a file at /apps/someResourceType/bundleresource.esp. The script file could
> contain the code:
> "BundleResource script, <%=currentNode.path%>"
> 3. Using WebDAV, create a script at /apps/someResourceType/webdav.esp. The
> script file could contain the code:
>"WebDAV-uploaded script, <%=currentNode.path%>"
> 4. Create a node /test, with sling:resourceType=someResourceType
> 5. Browse to http://localhost:8080/apps/someResourceType/bundleresource.esp,
> and assert that the source code of the script file is displayed
> 6. Browse to http://localhost:8080/system/console/bundleresources, and assert
> that the /apps resource is listed
> 7. Browse to http://localhost:8080/test.webdav, and assert that the
> WebDAV-uploaded script is used to render the node (displaying
> "WebDAV-uploaded script, /test")
> 8. Browse to http://localhost:8080/test.bundleresource
> Expected result:
> - The bundleresource-provided script is used to render the node, displaying
> "BundleResource script, /test"
> Actual result:
> - 403 Forbidden
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1181) Scripts loaded by Bundle Resource Provider are not found in script resolution
[ https://issues.apache.org/jira/browse/SLING-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776522#action_12776522 ] Ian Boston commented on SLING-1181: --- When a ResourceProvider was added in the old system it would be consukted if the path started with the path where the resource provider was added. BundleResourceProviders are added with /apps meaning anything starting with /apps is given to that resource provider, as well as any others eg /apps/sling/default/servlet/GET In the new system the assumption (incorrectly was made that we only consulted providers at the end of a path. Hence is 1 provider P1 was added at /apps and another P2 added at /apps/sling and we searched for a resource at /apps/sling/testing only P2 would be consulted, but P1 handles /apps/sling/testing We need to add all providers at /apps /apps/sling /apps/sling/testing eg P1 *and* P2 to get the completed list Or at least I think thats whats happening since we are not getting the BundleResourceProvider consulted when listing children. > Scripts loaded by Bundle Resource Provider are not found in script resolution > - > > Key: SLING-1181 > URL: https://issues.apache.org/jira/browse/SLING-1181 > Project: Sling > Issue Type: Bug >Reporter: Vidar S. Ramdal >Assignee: Ian Boston >Priority: Critical > Attachments: SLING-1181-test-bundle-source-and-jar.zip > > > When a script file is loaded as a bundle resource (using > Sling-Bundle-Resources directive), it is not picked up during script > resolution. > The bundle resource IS listed at /system/console/bundleresources, and the > script source is available at its URL under /apps. > I can reproduce this problem using the latest trunk build (rev #834413), but > not in builds prior to rev#825679. I will try to narrow it down, to find the > actual change causing this. > To reproduce: > 1. Run a fresh Sling build > 2. Upload a bundle with a > /apps directive, containing > a file at /apps/someResourceType/bundleresource.esp. The script file could > contain the code: > "BundleResource script, <%=currentNode.path%>" > 3. Using WebDAV, create a script at /apps/someResourceType/webdav.esp. The > script file could contain the code: >"WebDAV-uploaded script, <%=currentNode.path%>" > 4. Create a node /test, with sling:resourceType=someResourceType > 5. Browse to http://localhost:8080/apps/someResourceType/bundleresource.esp, > and assert that the source code of the script file is displayed > 6. Browse to http://localhost:8080/system/console/bundleresources, and assert > that the /apps resource is listed > 7. Browse to http://localhost:8080/test.webdav, and assert that the > WebDAV-uploaded script is used to render the node (displaying > "WebDAV-uploaded script, /test") > 8. Browse to http://localhost:8080/test.bundleresource > Expected result: > - The bundleresource-provided script is used to render the node, displaying > "BundleResource script, /test" > Actual result: > - 403 Forbidden -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1181) Scripts loaded by Bundle Resource Provider are not found in script resolution
[
https://issues.apache.org/jira/browse/SLING-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776598#action_12776598
]
Ian Boston commented on SLING-1181:
---
I believe I might have a fix, now getting the following, but need to do some
more testing.
x43543-2:resource ieb$ curl http://localhost:8080/apps.tidy.5.json
{
"jcr:created": "Wed Nov 11 2009 17:43:30 GMT+",
"jcr:primaryType": "sling:Folder",
"someResourceType": {
"bundleresource.esp": {
}
},
"sling": {
"jcr:created": "Wed Nov 11 2009 17:43:30 GMT+",
"jcr:primaryType": "sling:Folder",
"servlet": {
"jcr:created": "Wed Nov 11 2009 17:43:30 GMT+",
"jcr:primaryType": "sling:Folder",
"default": {
> Scripts loaded by Bundle Resource Provider are not found in script resolution
> -
>
> Key: SLING-1181
> URL: https://issues.apache.org/jira/browse/SLING-1181
> Project: Sling
> Issue Type: Bug
>Reporter: Vidar S. Ramdal
>Assignee: Ian Boston
>Priority: Critical
> Attachments: SLING-1181-test-bundle-source-and-jar.zip
>
>
> When a script file is loaded as a bundle resource (using
> Sling-Bundle-Resources directive), it is not picked up during script
> resolution.
> The bundle resource IS listed at /system/console/bundleresources, and the
> script source is available at its URL under /apps.
> I can reproduce this problem using the latest trunk build (rev #834413), but
> not in builds prior to rev#825679. I will try to narrow it down, to find the
> actual change causing this.
> To reproduce:
> 1. Run a fresh Sling build
> 2. Upload a bundle with a
> /apps directive, containing
> a file at /apps/someResourceType/bundleresource.esp. The script file could
> contain the code:
> "BundleResource script, <%=currentNode.path%>"
> 3. Using WebDAV, create a script at /apps/someResourceType/webdav.esp. The
> script file could contain the code:
>"WebDAV-uploaded script, <%=currentNode.path%>"
> 4. Create a node /test, with sling:resourceType=someResourceType
> 5. Browse to http://localhost:8080/apps/someResourceType/bundleresource.esp,
> and assert that the source code of the script file is displayed
> 6. Browse to http://localhost:8080/system/console/bundleresources, and assert
> that the /apps resource is listed
> 7. Browse to http://localhost:8080/test.webdav, and assert that the
> WebDAV-uploaded script is used to render the node (displaying
> "WebDAV-uploaded script, /test")
> 8. Browse to http://localhost:8080/test.bundleresource
> Expected result:
> - The bundleresource-provided script is used to render the node, displaying
> "BundleResource script, /test"
> Actual result:
> - 403 Forbidden
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1156) ResourceProviderEntry uses iterators rather than maps, this becomes expensive with apps with many servlets.
[ https://issues.apache.org/jira/browse/SLING-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston resolved SLING-1156. --- Resolution: Fixed Fix Version/s: JCR Resource 2.0.8 Re-resolving this, SLING-1181 represents a bug in this code, and has been fixed under that issue. > ResourceProviderEntry uses iterators rather than maps, this becomes expensive > with apps with many servlets. > --- > > Key: SLING-1156 > URL: https://issues.apache.org/jira/browse/SLING-1156 > Project: Sling > Issue Type: Improvement > Components: JCR >Affects Versions: JCR Resource 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: JCR Resource 2.0.8 > > > The ResourceProviderEntry uses iterators over many servlets, this is probably > Ok for Resource resolution but when it comes to servlet resolution many are > tested and this can be expensive especially if there are many servlets. IMHO, > the class should be refactored to use trees of maps. > This has been discussed on list, the intention is to create a contrib version > to explore this further, not wanting to impact the active version in trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1181) Scripts loaded by Bundle Resource Provider are not found in script resolution
[ https://issues.apache.org/jira/browse/SLING-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston resolved SLING-1181. --- Resolution: Fixed Fix Version/s: JCR Resource 2.0.8 Fixed in r834886 ResourceProviders that are registered in an existing tree of ResourceProviders are now capable of listing all the resources that they manage. Previously only leaf ResourceProviderEntries would list all their resources. > Scripts loaded by Bundle Resource Provider are not found in script resolution > - > > Key: SLING-1181 > URL: https://issues.apache.org/jira/browse/SLING-1181 > Project: Sling > Issue Type: Bug >Reporter: Vidar S. Ramdal >Assignee: Ian Boston >Priority: Critical > Fix For: JCR Resource 2.0.8 > > Attachments: SLING-1181-test-bundle-source-and-jar.zip > > > When a script file is loaded as a bundle resource (using > Sling-Bundle-Resources directive), it is not picked up during script > resolution. > The bundle resource IS listed at /system/console/bundleresources, and the > script source is available at its URL under /apps. > I can reproduce this problem using the latest trunk build (rev #834413), but > not in builds prior to rev#825679. I will try to narrow it down, to find the > actual change causing this. > To reproduce: > 1. Run a fresh Sling build > 2. Upload a bundle with a > /apps directive, containing > a file at /apps/someResourceType/bundleresource.esp. The script file could > contain the code: > "BundleResource script, <%=currentNode.path%>" > 3. Using WebDAV, create a script at /apps/someResourceType/webdav.esp. The > script file could contain the code: >"WebDAV-uploaded script, <%=currentNode.path%>" > 4. Create a node /test, with sling:resourceType=someResourceType > 5. Browse to http://localhost:8080/apps/someResourceType/bundleresource.esp, > and assert that the source code of the script file is displayed > 6. Browse to http://localhost:8080/system/console/bundleresources, and assert > that the /apps resource is listed > 7. Browse to http://localhost:8080/test.webdav, and assert that the > WebDAV-uploaded script is used to render the node (displaying > "WebDAV-uploaded script, /test") > 8. Browse to http://localhost:8080/test.bundleresource > Expected result: > - The bundleresource-provided script is used to render the node, displaying > "BundleResource script, /test" > Actual result: > - 403 Forbidden -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1181) Scripts loaded by Bundle Resource Provider are not found in script resolution
[ https://issues.apache.org/jira/browse/SLING-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776906#action_12776906 ] Ian Boston commented on SLING-1181: --- Sorry, my fault, 835298 rebased my local git repo but stupidly omitted to dcommit back to svn. > Scripts loaded by Bundle Resource Provider are not found in script resolution > - > > Key: SLING-1181 > URL: https://issues.apache.org/jira/browse/SLING-1181 > Project: Sling > Issue Type: Bug >Reporter: Vidar S. Ramdal >Assignee: Ian Boston >Priority: Critical > Fix For: JCR Resource 2.0.8 > > Attachments: SLING-1181-test-bundle-source-and-jar.zip > > > When a script file is loaded as a bundle resource (using > Sling-Bundle-Resources directive), it is not picked up during script > resolution. > The bundle resource IS listed at /system/console/bundleresources, and the > script source is available at its URL under /apps. > I can reproduce this problem using the latest trunk build (rev #834413), but > not in builds prior to rev#825679. I will try to narrow it down, to find the > actual change causing this. > To reproduce: > 1. Run a fresh Sling build > 2. Upload a bundle with a > /apps directive, containing > a file at /apps/someResourceType/bundleresource.esp. The script file could > contain the code: > "BundleResource script, <%=currentNode.path%>" > 3. Using WebDAV, create a script at /apps/someResourceType/webdav.esp. The > script file could contain the code: >"WebDAV-uploaded script, <%=currentNode.path%>" > 4. Create a node /test, with sling:resourceType=someResourceType > 5. Browse to http://localhost:8080/apps/someResourceType/bundleresource.esp, > and assert that the source code of the script file is displayed > 6. Browse to http://localhost:8080/system/console/bundleresources, and assert > that the /apps resource is listed > 7. Browse to http://localhost:8080/test.webdav, and assert that the > WebDAV-uploaded script is used to render the node (displaying > "WebDAV-uploaded script, /test") > 8. Browse to http://localhost:8080/test.bundleresource > Expected result: > - The bundleresource-provided script is used to render the node, displaying > "BundleResource script, /test" > Actual result: > - 403 Forbidden -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1189) When comparing SNAPSHOT-versioned bundles, also check the Bnd-LastModified Header
[ https://issues.apache.org/jira/browse/SLING-1189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778855#action_12778855 ] Ian Boston commented on SLING-1189: --- So the following is just my 2c's worth. The launchpad's job is to build a structure which the OSGi container can start up in, IIUC it unpacks its contents into a Felix managed environment and then hands over control to the Felix environment. Users may then manipulate that environment using Felix tools doing all sorts of things, unknown (like even downgrading a bundle). Normally on second starts the launchpad just sees that Felix has a working copy (which may have been reconfigured) and does not touch it, but hands control over to Felix. IMVHO, it would be wrong for the launchpad to modify the Felix environment based on what it has internally since it has absolutely no idea what configuration and user actions might have been taken by users to configure the Felix environment post launch. I know for a fact that the development community that I am working with relies on this behavior to customise layout and configuration post launch to achieve different aims. (Non java UI developers loading different sets of bundles to get a edit-browser refresh cycle, sometimes older versions) for that use, this patch would cause problems. Sorry. > When comparing SNAPSHOT-versioned bundles, also check the Bnd-LastModified > Header > - > > Key: SLING-1189 > URL: https://issues.apache.org/jira/browse/SLING-1189 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Reporter: Justin Edelson > Attachments: SLING-1189.patch > > > As an enhancement to the functionality provided with SLING-1162, if a bundle > in resources/bundles/ is already installed with the same version > and the version ends in SNAPSHOT, if both bundles include a Bnd-LastModified > header, use that header as an additional check. > The current implementation fails under this use case: > 1) SNAPSHOT included in the WAR/JAR file. > 2) newer SNAPSHOT installed via console/shell > 3) App is restarted > At this point, the original SNAPSHOT will be installed, not the newer one > included. > I'll have a patch for this soonish. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1189) When comparing SNAPSHOT-versioned bundles, also check the Bnd-LastModified Header
[ https://issues.apache.org/jira/browse/SLING-1189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778907#action_12778907 ] Ian Boston commented on SLING-1189: --- I wasn't aware of the current update behavior, or I have a local bug, as I always need to zap the Felix bundles to to reload the jars. In which case, I'm ok with the proposal, consider my objections/observations withdrawn. I dont think there is a need for a switch, as you observe that would be confusing. Ian > When comparing SNAPSHOT-versioned bundles, also check the Bnd-LastModified > Header > - > > Key: SLING-1189 > URL: https://issues.apache.org/jira/browse/SLING-1189 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Reporter: Justin Edelson > Attachments: SLING-1189.patch > > > As an enhancement to the functionality provided with SLING-1162, if a bundle > in resources/bundles/ is already installed with the same version > and the version ends in SNAPSHOT, if both bundles include a Bnd-LastModified > header, use that header as an additional check. > The current implementation fails under this use case: > 1) SNAPSHOT included in the WAR/JAR file. > 2) newer SNAPSHOT installed via console/shell > 3) App is restarted > At this point, the original SNAPSHOT will be installed, not the newer one > included. > I'll have a patch for this soonish. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1023) Allow NonExistant Resources to have a Resource Type
[ https://issues.apache.org/jira/browse/SLING-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston resolved SLING-1023. --- Resolution: Invalid This is now invalid after the update to ResourceProviderEntry Resolving. > Allow NonExistant Resources to have a Resource Type > --- > > Key: SLING-1023 > URL: https://issues.apache.org/jira/browse/SLING-1023 > Project: Sling > Issue Type: Improvement > Components: JCR >Affects Versions: JCR Resource 2.0.4 >Reporter: Ian Boston > Attachments: SLING-1023.patch > > > We have been using a patch to the jcr.resolver bundle that allows us to map > non existent resources to a resource type so that they can be handled by a > servlet registered to that resource type. Our use case is to allow a node to > act as a marker and container for the virtual store where the URL path does > not equal the JCR storage path. > eg the URL > /_user/messages/ieb/101 > maps to > /_user/messages/ed/fe/45/3e/ieb/23/ef/e4/d0/101 > where only the node > /_user/messages is marked with a resource type. > Patch to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-1083) Node copy with :replace fails
[ https://issues.apache.org/jira/browse/SLING-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston reassigned SLING-1083: - Assignee: Ian Boston > Node copy with :replace fails > - > > Key: SLING-1083 > URL: https://issues.apache.org/jira/browse/SLING-1083 > Project: Sling > Issue Type: Bug > Components: Servlets >Affects Versions: Servlets Post 2.0.2 > Environment: J2SE 1.6.0_14-b08, Debian Linux >Reporter: Arthur Taylor >Assignee: Ian Boston > Attachments: test-replace.sh > > > Attempting to copy a node to the location of an existing node fails with a > PathNotFoundException, generated by the call to session.getItem() at line 136 > of AbstractMoveCopyOperation.java. The attached script demonstrates the > failure. > By introducing a breakpoint in CopyOperation.java's copy(Node src, Node > dstParent, String name) anywhere after the replacement node is created (line > 109), I've been able to make requests succeed. It seems as though there must > be a race or a caching issue there. > Stack trace: > 13.08.2009 13:16:10.374 *ERROR* [127.0.0.1 [1250165770368] POST /d1 HTTP/1.1] > org.apache.sling.servlets.post.impl.operations.CopyOperation Exception during > response processing. javax.jcr.PathNotFoundException: /d2 > at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:442) > at org.apache.jackrabbit.core.SessionImpl.getItem(SessionImpl.java:805) > at > org.apache.sling.jcr.base.internal.PooledSession.getItem(PooledSession.java:158) > at > org.apache.sling.servlets.post.impl.operations.AbstractCopyMoveOperation.doRun(AbstractCopyMoveOperation.java:136) > at > org.apache.sling.servlets.post.AbstractSlingPostOperation.run(AbstractSlingPostOperation.java:87) > at > org.apache.sling.servlets.post.impl.SlingPostServlet.doPost(SlingPostServlet.java:172) > at > org.apache.sling.api.servlets.SlingAllMethodsServlet.mayService(SlingAllMethodsServlet.java:143) > at > org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:338) > at > org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:369) > at > org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:520) > at > org.apache.sling.engine.impl.SlingMainServlet.processRequest(SlingMainServlet.java:409) > at > org.apache.sling.engine.impl.filter.RequestSlingFilterChain.render(RequestSlingFilterChain.java:48) > at > org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:59) > at > org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter.doFilter(RequestProgressTrackerLogFilter.java:59) > at > org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:57) > at > org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:296) > at > org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:183) > at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502) > at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:389) > at > org.ops4j.pax.web.service.internal.HttpServiceServletHandler.handle(HttpServiceServletHandler.java:64) > at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) > at > org.ops4j.pax.web.service.internal.HttpServiceContext.handle(HttpServiceContext.java:111) > at > org.ops4j.pax.web.service.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:64) > at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) > at org.mortbay.jetty.Server.handle(Server.java:324) > at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:535) > at > org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:880) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) > at > org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:520) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1083) Node copy with :replace fails
[ https://issues.apache.org/jira/browse/SLING-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston resolved SLING-1083. --- Resolution: Cannot Reproduce Fix Version/s: Servlets Post 2.0.6 Testing against post 2.0.5-SNAPSHOT I am unable to reproduce with JDK 16. on OSX. resolving as such. > Node copy with :replace fails > - > > Key: SLING-1083 > URL: https://issues.apache.org/jira/browse/SLING-1083 > Project: Sling > Issue Type: Bug > Components: Servlets >Affects Versions: Servlets Post 2.0.2 > Environment: J2SE 1.6.0_14-b08, Debian Linux >Reporter: Arthur Taylor >Assignee: Ian Boston > Fix For: Servlets Post 2.0.6 > > Attachments: test-replace.sh > > > Attempting to copy a node to the location of an existing node fails with a > PathNotFoundException, generated by the call to session.getItem() at line 136 > of AbstractMoveCopyOperation.java. The attached script demonstrates the > failure. > By introducing a breakpoint in CopyOperation.java's copy(Node src, Node > dstParent, String name) anywhere after the replacement node is created (line > 109), I've been able to make requests succeed. It seems as though there must > be a race or a caching issue there. > Stack trace: > 13.08.2009 13:16:10.374 *ERROR* [127.0.0.1 [1250165770368] POST /d1 HTTP/1.1] > org.apache.sling.servlets.post.impl.operations.CopyOperation Exception during > response processing. javax.jcr.PathNotFoundException: /d2 > at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:442) > at org.apache.jackrabbit.core.SessionImpl.getItem(SessionImpl.java:805) > at > org.apache.sling.jcr.base.internal.PooledSession.getItem(PooledSession.java:158) > at > org.apache.sling.servlets.post.impl.operations.AbstractCopyMoveOperation.doRun(AbstractCopyMoveOperation.java:136) > at > org.apache.sling.servlets.post.AbstractSlingPostOperation.run(AbstractSlingPostOperation.java:87) > at > org.apache.sling.servlets.post.impl.SlingPostServlet.doPost(SlingPostServlet.java:172) > at > org.apache.sling.api.servlets.SlingAllMethodsServlet.mayService(SlingAllMethodsServlet.java:143) > at > org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:338) > at > org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:369) > at > org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:520) > at > org.apache.sling.engine.impl.SlingMainServlet.processRequest(SlingMainServlet.java:409) > at > org.apache.sling.engine.impl.filter.RequestSlingFilterChain.render(RequestSlingFilterChain.java:48) > at > org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:59) > at > org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter.doFilter(RequestProgressTrackerLogFilter.java:59) > at > org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:57) > at > org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:296) > at > org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:183) > at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502) > at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:389) > at > org.ops4j.pax.web.service.internal.HttpServiceServletHandler.handle(HttpServiceServletHandler.java:64) > at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) > at > org.ops4j.pax.web.service.internal.HttpServiceContext.handle(HttpServiceContext.java:111) > at > org.ops4j.pax.web.service.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:64) > at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) > at org.mortbay.jetty.Server.handle(Server.java:324) > at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:535) > at > org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:880) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) > at > org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:520) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1263) PluggableDefaultAccessManager bypasses some logic in isGranted super class.
PluggableDefaultAccessManager bypasses some logic in isGranted super class. --- Key: SLING-1263 URL: https://issues.apache.org/jira/browse/SLING-1263 Project: Sling Issue Type: Bug Components: JCR Affects Versions: JCR Jackrabbit Server 2.0.4 Reporter: Ian Boston Assignee: Ian Boston Fix For: JCR Jackrabbit Server 2.0.6 see discussion at http://markmail.org/thread/nldwjcauv36i62ha in short isGranted(ItemId itemId, int permissions) should be return super.isGranted(itemId, permissions) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1263) PluggableDefaultAccessManager bypasses some logic in isGranted super class.
[ https://issues.apache.org/jira/browse/SLING-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston resolved SLING-1263. --- Resolution: Fixed I have made a fix, with some cleanup on unused properties, builds and passes all tests, but if there are any problems it should be easy enough to revert. > PluggableDefaultAccessManager bypasses some logic in isGranted super class. > --- > > Key: SLING-1263 > URL: https://issues.apache.org/jira/browse/SLING-1263 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR Jackrabbit Server 2.0.4 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: JCR Jackrabbit Server 2.0.6 > > > see discussion at http://markmail.org/thread/nldwjcauv36i62ha > in short isGranted(ItemId itemId, int permissions) should be return > super.isGranted(itemId, permissions) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1251) contentloader security:acl handling broken by Jackrabbit 1.6
[
https://issues.apache.org/jira/browse/SLING-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797833#action_12797833
]
Ian Boston commented on SLING-1251:
---
Patch looks good after reading, will try and apply and run tests.
> contentloader security:acl handling broken by Jackrabbit 1.6
>
>
> Key: SLING-1251
> URL: https://issues.apache.org/jira/browse/SLING-1251
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Affects Versions: JCR ContentLoader 2.0.8
>Reporter: Ray Davis
> Attachments: SLING-1251.patch
>
>
> After building rev 892191, I loaded a bundle with a JSON descriptor file
> including access control initialization as described in SLING-981:
>"security:acl" : [
>{
>"principal" : "everyone",
>"granted" : [
>"jcr:removeChildNodes"
>]
>}
> On bundle activation, an exception was thrown:
> *ERROR* [SCR Component Actor]
> org.apache.sling.jcr.contentloader.internal.Loader Cannot load initial
> content for bundle org.sakaiproject.kernel.site : Unable to find an access
> conrol policy to update. javax.jcr.RepositoryException: Unable to find an
> access conrol policy to update.
> at
> org.apache.sling.jcr.contentloader.internal.DefaultContentCreator.createAce(DefaultContentCreator.java:825)
> at
> org.apache.sling.jcr.contentloader.internal.readers.JsonReader.createAce(JsonReader.java:425)
> at
> org.apache.sling.jcr.contentloader.internal.readers.JsonReader.createAcl(JsonReader.java:391)
> at
> org.apache.sling.jcr.contentloader.internal.readers.JsonReader.createNode(JsonReader.java:193)
> at
> org.apache.sling.jcr.contentloader.internal.readers.JsonReader.parse(JsonReader.java:157)
> at
> org.apache.sling.jcr.contentloader.internal.readers.JsonReader.parse(JsonReader.java:138)
> at
> org.apache.sling.jcr.contentloader.internal.Loader.createNode(Loader.java:518)
> This is caused by the same issue as SLING-1208. A change in the Jackrabbit
> 1.6 AccessControlManager means we need to try calling getPolicies as well as
> getApplicablePolicies.
> I'll upload a patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-1251) contentloader security:acl handling broken by Jackrabbit 1.6
[
https://issues.apache.org/jira/browse/SLING-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Boston reassigned SLING-1251:
-
Assignee: Ian Boston
> contentloader security:acl handling broken by Jackrabbit 1.6
>
>
> Key: SLING-1251
> URL: https://issues.apache.org/jira/browse/SLING-1251
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Affects Versions: JCR ContentLoader 2.0.8
>Reporter: Ray Davis
>Assignee: Ian Boston
> Attachments: SLING-1251.patch
>
>
> After building rev 892191, I loaded a bundle with a JSON descriptor file
> including access control initialization as described in SLING-981:
>"security:acl" : [
>{
>"principal" : "everyone",
>"granted" : [
>"jcr:removeChildNodes"
>]
>}
> On bundle activation, an exception was thrown:
> *ERROR* [SCR Component Actor]
> org.apache.sling.jcr.contentloader.internal.Loader Cannot load initial
> content for bundle org.sakaiproject.kernel.site : Unable to find an access
> conrol policy to update. javax.jcr.RepositoryException: Unable to find an
> access conrol policy to update.
> at
> org.apache.sling.jcr.contentloader.internal.DefaultContentCreator.createAce(DefaultContentCreator.java:825)
> at
> org.apache.sling.jcr.contentloader.internal.readers.JsonReader.createAce(JsonReader.java:425)
> at
> org.apache.sling.jcr.contentloader.internal.readers.JsonReader.createAcl(JsonReader.java:391)
> at
> org.apache.sling.jcr.contentloader.internal.readers.JsonReader.createNode(JsonReader.java:193)
> at
> org.apache.sling.jcr.contentloader.internal.readers.JsonReader.parse(JsonReader.java:157)
> at
> org.apache.sling.jcr.contentloader.internal.readers.JsonReader.parse(JsonReader.java:138)
> at
> org.apache.sling.jcr.contentloader.internal.Loader.createNode(Loader.java:518)
> This is caused by the same issue as SLING-1208. A change in the Jackrabbit
> 1.6 AccessControlManager means we need to try calling getPolicies as well as
> getApplicablePolicies.
> I'll upload a patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1251) contentloader security:acl handling broken by Jackrabbit 1.6
[
https://issues.apache.org/jira/browse/SLING-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Boston updated SLING-1251:
--
Affects Version/s: (was: JCR ContentLoader 2.0.8)
JCR Contentloader 2.0.6
Fix Version/s: JCR Contentloader 2.0.6
Correcting affects and fix, (affects 2.0.5-SNAPSHOT, code was not in 2.0.4 and
2.0.8 isnt on the cards yet)
> contentloader security:acl handling broken by Jackrabbit 1.6
>
>
> Key: SLING-1251
> URL: https://issues.apache.org/jira/browse/SLING-1251
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Affects Versions: JCR Contentloader 2.0.6
>Reporter: Ray Davis
>Assignee: Ian Boston
> Fix For: JCR Contentloader 2.0.6
>
> Attachments: SLING-1251.patch
>
>
> After building rev 892191, I loaded a bundle with a JSON descriptor file
> including access control initialization as described in SLING-981:
>"security:acl" : [
>{
>"principal" : "everyone",
>"granted" : [
>"jcr:removeChildNodes"
>]
>}
> On bundle activation, an exception was thrown:
> *ERROR* [SCR Component Actor]
> org.apache.sling.jcr.contentloader.internal.Loader Cannot load initial
> content for bundle org.sakaiproject.kernel.site : Unable to find an access
> conrol policy to update. javax.jcr.RepositoryException: Unable to find an
> access conrol policy to update.
> at
> org.apache.sling.jcr.contentloader.internal.DefaultContentCreator.createAce(DefaultContentCreator.java:825)
> at
> org.apache.sling.jcr.contentloader.internal.readers.JsonReader.createAce(JsonReader.java:425)
> at
> org.apache.sling.jcr.contentloader.internal.readers.JsonReader.createAcl(JsonReader.java:391)
> at
> org.apache.sling.jcr.contentloader.internal.readers.JsonReader.createNode(JsonReader.java:193)
> at
> org.apache.sling.jcr.contentloader.internal.readers.JsonReader.parse(JsonReader.java:157)
> at
> org.apache.sling.jcr.contentloader.internal.readers.JsonReader.parse(JsonReader.java:138)
> at
> org.apache.sling.jcr.contentloader.internal.Loader.createNode(Loader.java:518)
> This is caused by the same issue as SLING-1208. A change in the Jackrabbit
> 1.6 AccessControlManager means we need to try calling getPolicies as well as
> getApplicablePolicies.
> I'll upload a patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1251) contentloader security:acl handling broken by Jackrabbit 1.6
[
https://issues.apache.org/jira/browse/SLING-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Boston resolved SLING-1251.
---
Resolution: Fixed
Patch applied, builds fine and passes all tests. Many Thanks.
> contentloader security:acl handling broken by Jackrabbit 1.6
>
>
> Key: SLING-1251
> URL: https://issues.apache.org/jira/browse/SLING-1251
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Affects Versions: JCR Contentloader 2.0.6
>Reporter: Ray Davis
>Assignee: Ian Boston
> Fix For: JCR Contentloader 2.0.6
>
> Attachments: SLING-1251.patch
>
>
> After building rev 892191, I loaded a bundle with a JSON descriptor file
> including access control initialization as described in SLING-981:
>"security:acl" : [
>{
>"principal" : "everyone",
>"granted" : [
>"jcr:removeChildNodes"
>]
>}
> On bundle activation, an exception was thrown:
> *ERROR* [SCR Component Actor]
> org.apache.sling.jcr.contentloader.internal.Loader Cannot load initial
> content for bundle org.sakaiproject.kernel.site : Unable to find an access
> conrol policy to update. javax.jcr.RepositoryException: Unable to find an
> access conrol policy to update.
> at
> org.apache.sling.jcr.contentloader.internal.DefaultContentCreator.createAce(DefaultContentCreator.java:825)
> at
> org.apache.sling.jcr.contentloader.internal.readers.JsonReader.createAce(JsonReader.java:425)
> at
> org.apache.sling.jcr.contentloader.internal.readers.JsonReader.createAcl(JsonReader.java:391)
> at
> org.apache.sling.jcr.contentloader.internal.readers.JsonReader.createNode(JsonReader.java:193)
> at
> org.apache.sling.jcr.contentloader.internal.readers.JsonReader.parse(JsonReader.java:157)
> at
> org.apache.sling.jcr.contentloader.internal.readers.JsonReader.parse(JsonReader.java:138)
> at
> org.apache.sling.jcr.contentloader.internal.Loader.createNode(Loader.java:518)
> This is caused by the same issue as SLING-1208. A change in the Jackrabbit
> 1.6 AccessControlManager means we need to try calling getPolicies as well as
> getApplicablePolicies.
> I'll upload a patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1281) Copy Move operations dont work.
Copy Move operations dont work. --- Key: SLING-1281 URL: https://issues.apache.org/jira/browse/SLING-1281 Project: Sling Issue Type: Bug Affects Versions: Servlets Post 2.0.6, JCR Jackrabbit Server 2.0.6 Reporter: Ian Boston To reproduce: Create 2 content items: * curl -X POST http://localhost:8080/d1 -u admin:admin * curl -X POST http://localhost:8080/d2 -u admin:admin Attempt to copy one item on top of the other: * curl -F ":operation=copy" -F ":dest=d2" http://localhost:8080/d1 -u admin:admin Correctly encounter: 412 "Cannot copy JcrNodeResource, type=nt:unstructured, path=/d1 to /d2: destination exists" Attempt to copy one item on top of the other with :replace set to true: * curl -F ":operation=copy" -F ":dest=d2" -F ":replace=true" http://localhost:8080/d1 -u admin:admin This should now succeed, however, it is returning: 500 javax.jcr.PathNotFoundException: /d2 and we know for sure /d2 exists! I think this might be related to changes in the pooling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1282) Adminisrative logins depend on password in the code or config
Adminisrative logins depend on password in the code or config - Key: SLING-1282 URL: https://issues.apache.org/jira/browse/SLING-1282 Project: Sling Issue Type: Bug Components: JCR Affects Versions: JCR Jackrabbit Server 2.0.6 Reporter: Ian Boston Assignee: Ian Boston Fix For: JCR Jackrabbit Server 2.0.6 Administrative logins use SimpleCredentials which means that they have to have a password. Although this is a configuration parameter changing the admin password creates some JVM timing difficulties especially when operating in a cluster. (JVMs would probably need to be restarted with new config immediately after changing the admin password.) It would be better to use special credentials to indicate internal logins to the repository (eg public final class AdministrativeCredentials implements Credentials) same is true for Anon/Guest users, although less important. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1281) Copy Move operations dont work.
[ https://issues.apache.org/jira/browse/SLING-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston updated SLING-1281: -- Attachment: test-SLING-1281.sh Script to reproduce the problem > Copy Move operations dont work. > --- > > Key: SLING-1281 > URL: https://issues.apache.org/jira/browse/SLING-1281 > Project: Sling > Issue Type: Bug >Affects Versions: Servlets Post 2.0.6, JCR Jackrabbit Server 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston > Attachments: test-SLING-1281.sh > > > To reproduce: > Create 2 content items: > * curl -X POST http://localhost:8080/d1 -u admin:admin > * curl -X POST http://localhost:8080/d2 -u admin:admin > Attempt to copy one item on top of the other: > * curl -F ":operation=copy" -F ":dest=d2" http://localhost:8080/d1 -u > admin:admin > Correctly encounter: 412 "Cannot copy JcrNodeResource, type=nt:unstructured, > path=/d1 to /d2: destination exists" > Attempt to copy one item on top of the other with :replace set to true: > * curl -F ":operation=copy" -F ":dest=d2" -F ":replace=true" > http://localhost:8080/d1 -u admin:admin > This should now succeed, however, it is returning: > 500 javax.jcr.PathNotFoundException: /d2 > and we know for sure /d2 exists! > I think this might be related to changes in the pooling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-1281) Copy Move operations dont work.
[ https://issues.apache.org/jira/browse/SLING-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston reassigned SLING-1281: - Assignee: Ian Boston > Copy Move operations dont work. > --- > > Key: SLING-1281 > URL: https://issues.apache.org/jira/browse/SLING-1281 > Project: Sling > Issue Type: Bug >Affects Versions: Servlets Post 2.0.6, JCR Jackrabbit Server 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston > Attachments: test-SLING-1281.sh > > > To reproduce: > Create 2 content items: > * curl -X POST http://localhost:8080/d1 -u admin:admin > * curl -X POST http://localhost:8080/d2 -u admin:admin > Attempt to copy one item on top of the other: > * curl -F ":operation=copy" -F ":dest=d2" http://localhost:8080/d1 -u > admin:admin > Correctly encounter: 412 "Cannot copy JcrNodeResource, type=nt:unstructured, > path=/d1 to /d2: destination exists" > Attempt to copy one item on top of the other with :replace set to true: > * curl -F ":operation=copy" -F ":dest=d2" -F ":replace=true" > http://localhost:8080/d1 -u admin:admin > This should now succeed, however, it is returning: > 500 javax.jcr.PathNotFoundException: /d2 > and we know for sure /d2 exists! > I think this might be related to changes in the pooling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1281) Copy Move operations dont work.
[
https://issues.apache.org/jira/browse/SLING-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798675#action_12798675
]
Ian Boston commented on SLING-1281:
---
Checking the sequence of operations.
session.getItem("/d2-") goes into ItemImpl that retrieves a ItemId fromt he
path from the Hierarchy manager, that itemsId is not found.
Looking that the resolution of ItemId to item, eventually the
SessionItemStateManager looks for the ItemData from cache. Line 181 checks to
see if the item has been removed, (d2 was removed earlier in the copy
operation), and finds atticStore does indeed contain the item. However
getTransientItemState(id) only looks in the transientStore which from the doc
is only used for new and modified items, not removed items.
Looking at hasItemState(id) for a the SessionItemStateManager to return an
item, if in the atticStore it must also be in the transientStore (since it was
deleted and then created new again), otherwise it does not exist.
Two observations here.
The /d2 node was removed, so it should be in the atticStore, but it should have
been created by a new copy and so be in the transientStore.
Need to check what happens if we copy to a node that doesnt exist, so doesnt
need to be removed, and if the node really is created by the copy operation.
> Copy Move operations dont work.
> ---
>
> Key: SLING-1281
> URL: https://issues.apache.org/jira/browse/SLING-1281
> Project: Sling
> Issue Type: Bug
>Affects Versions: Servlets Post 2.0.6, JCR Jackrabbit Server 2.0.6
>Reporter: Ian Boston
>Assignee: Ian Boston
> Attachments: test-SLING-1281.sh
>
>
> To reproduce:
> Create 2 content items:
> * curl -X POST http://localhost:8080/d1 -u admin:admin
> * curl -X POST http://localhost:8080/d2 -u admin:admin
> Attempt to copy one item on top of the other:
> * curl -F ":operation=copy" -F ":dest=d2" http://localhost:8080/d1 -u
> admin:admin
> Correctly encounter: 412 "Cannot copy JcrNodeResource, type=nt:unstructured,
> path=/d1 to /d2: destination exists"
> Attempt to copy one item on top of the other with :replace set to true:
> * curl -F ":operation=copy" -F ":dest=d2" -F ":replace=true"
> http://localhost:8080/d1 -u admin:admin
> This should now succeed, however, it is returning:
> 500 javax.jcr.PathNotFoundException: /d2
> and we know for sure /d2 exists!
> I think this might be related to changes in the pooling.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1281) Copy Move operations dont work.
[ https://issues.apache.org/jira/browse/SLING-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798677#action_12798677 ] Ian Boston commented on SLING-1281: --- If the destination node does not already exist, then the copy works perfectly. Indicating the problem is with the remove and add of the destination node. > Copy Move operations dont work. > --- > > Key: SLING-1281 > URL: https://issues.apache.org/jira/browse/SLING-1281 > Project: Sling > Issue Type: Bug >Affects Versions: Servlets Post 2.0.6, JCR Jackrabbit Server 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston > Attachments: test-SLING-1281.sh > > > To reproduce: > Create 2 content items: > * curl -X POST http://localhost:8080/d1 -u admin:admin > * curl -X POST http://localhost:8080/d2 -u admin:admin > Attempt to copy one item on top of the other: > * curl -F ":operation=copy" -F ":dest=d2" http://localhost:8080/d1 -u > admin:admin > Correctly encounter: 412 "Cannot copy JcrNodeResource, type=nt:unstructured, > path=/d1 to /d2: destination exists" > Attempt to copy one item on top of the other with :replace set to true: > * curl -F ":operation=copy" -F ":dest=d2" -F ":replace=true" > http://localhost:8080/d1 -u admin:admin > This should now succeed, however, it is returning: > 500 javax.jcr.PathNotFoundException: /d2 > and we know for sure /d2 exists! > I think this might be related to changes in the pooling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1281) Copy Move operations dont work.
[ https://issues.apache.org/jira/browse/SLING-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston updated SLING-1281: -- Attachment: test-SLING-1281.sh Updated with the corrected response code. > Copy Move operations dont work. > --- > > Key: SLING-1281 > URL: https://issues.apache.org/jira/browse/SLING-1281 > Project: Sling > Issue Type: Bug >Affects Versions: Servlets Post 2.0.6, JCR Jackrabbit Server 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston > Attachments: test-SLING-1281.sh > > > To reproduce: > Create 2 content items: > * curl -X POST http://localhost:8080/d1 -u admin:admin > * curl -X POST http://localhost:8080/d2 -u admin:admin > Attempt to copy one item on top of the other: > * curl -F ":operation=copy" -F ":dest=d2" http://localhost:8080/d1 -u > admin:admin > Correctly encounter: 412 "Cannot copy JcrNodeResource, type=nt:unstructured, > path=/d1 to /d2: destination exists" > Attempt to copy one item on top of the other with :replace set to true: > * curl -F ":operation=copy" -F ":dest=d2" -F ":replace=true" > http://localhost:8080/d1 -u admin:admin > This should now succeed, however, it is returning: > 500 javax.jcr.PathNotFoundException: /d2 > and we know for sure /d2 exists! > I think this might be related to changes in the pooling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1281) Copy Move operations dont work.
[ https://issues.apache.org/jira/browse/SLING-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston updated SLING-1281: -- Attachment: (was: test-SLING-1281.sh) > Copy Move operations dont work. > --- > > Key: SLING-1281 > URL: https://issues.apache.org/jira/browse/SLING-1281 > Project: Sling > Issue Type: Bug >Affects Versions: Servlets Post 2.0.6, JCR Jackrabbit Server 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston > Attachments: test-SLING-1281.sh > > > To reproduce: > Create 2 content items: > * curl -X POST http://localhost:8080/d1 -u admin:admin > * curl -X POST http://localhost:8080/d2 -u admin:admin > Attempt to copy one item on top of the other: > * curl -F ":operation=copy" -F ":dest=d2" http://localhost:8080/d1 -u > admin:admin > Correctly encounter: 412 "Cannot copy JcrNodeResource, type=nt:unstructured, > path=/d1 to /d2: destination exists" > Attempt to copy one item on top of the other with :replace set to true: > * curl -F ":operation=copy" -F ":dest=d2" -F ":replace=true" > http://localhost:8080/d1 -u admin:admin > This should now succeed, however, it is returning: > 500 javax.jcr.PathNotFoundException: /d2 > and we know for sure /d2 exists! > I think this might be related to changes in the pooling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1281) Copy Move operations dont work.
[ https://issues.apache.org/jira/browse/SLING-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798696#action_12798696 ] Ian Boston commented on SLING-1281: --- Looks like the state of the parent node on /d2 is not saved, and hence isnt in the transientStore. adding a save puts it there and fixes this bug. > Copy Move operations dont work. > --- > > Key: SLING-1281 > URL: https://issues.apache.org/jira/browse/SLING-1281 > Project: Sling > Issue Type: Bug >Affects Versions: Servlets Post 2.0.6, JCR Jackrabbit Server 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston > Attachments: test-SLING-1281.sh > > > To reproduce: > Create 2 content items: > * curl -X POST http://localhost:8080/d1 -u admin:admin > * curl -X POST http://localhost:8080/d2 -u admin:admin > Attempt to copy one item on top of the other: > * curl -F ":operation=copy" -F ":dest=d2" http://localhost:8080/d1 -u > admin:admin > Correctly encounter: 412 "Cannot copy JcrNodeResource, type=nt:unstructured, > path=/d1 to /d2: destination exists" > Attempt to copy one item on top of the other with :replace set to true: > * curl -F ":operation=copy" -F ":dest=d2" -F ":replace=true" > http://localhost:8080/d1 -u admin:admin > This should now succeed, however, it is returning: > 500 javax.jcr.PathNotFoundException: /d2 > and we know for sure /d2 exists! > I think this might be related to changes in the pooling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1281) Copy Move operations dont work.
[ https://issues.apache.org/jira/browse/SLING-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston resolved SLING-1281. --- Resolution: Fixed Fix Version/s: Servlets Post 2.0.6 Fixed > Copy Move operations dont work. > --- > > Key: SLING-1281 > URL: https://issues.apache.org/jira/browse/SLING-1281 > Project: Sling > Issue Type: Bug >Affects Versions: Servlets Post 2.0.6, JCR Jackrabbit Server 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: Servlets Post 2.0.6 > > Attachments: test-SLING-1281.sh > > > To reproduce: > Create 2 content items: > * curl -X POST http://localhost:8080/d1 -u admin:admin > * curl -X POST http://localhost:8080/d2 -u admin:admin > Attempt to copy one item on top of the other: > * curl -F ":operation=copy" -F ":dest=d2" http://localhost:8080/d1 -u > admin:admin > Correctly encounter: 412 "Cannot copy JcrNodeResource, type=nt:unstructured, > path=/d1 to /d2: destination exists" > Attempt to copy one item on top of the other with :replace set to true: > * curl -F ":operation=copy" -F ":dest=d2" -F ":replace=true" > http://localhost:8080/d1 -u admin:admin > This should now succeed, however, it is returning: > 500 javax.jcr.PathNotFoundException: /d2 > and we know for sure /d2 exists! > I think this might be related to changes in the pooling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1281) Copy Move operations dont work.
[ https://issues.apache.org/jira/browse/SLING-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798703#action_12798703 ] Ian Boston commented on SLING-1281: --- I dont know if we can fix it differently. To fix the problem an item that is removed and then added will be present in the SessionItemStateManager.atticStore as its been removed, but it also needs to be present in the SessionItemStateManager.transientStore as that is where its expected to be. I suspect this is really a bug in Jackrabbit since the create operation should have put it in the session transientStore (?), but I am not certain about that, so the save is really a workarround. Is there another way of getting items into the SessionItemStateManager.transientStore ? Or should the Jackrabbit code really be looking in the atticStore. An alternative way might be to return the /d2 node from the copy operation avoiding the session.getItem operation altogether ? I can work up a patch for that. > Copy Move operations dont work. > --- > > Key: SLING-1281 > URL: https://issues.apache.org/jira/browse/SLING-1281 > Project: Sling > Issue Type: Bug >Affects Versions: Servlets Post 2.0.6, JCR Jackrabbit Server 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: Servlets Post 2.0.6 > > Attachments: test-SLING-1281.sh > > > To reproduce: > Create 2 content items: > * curl -X POST http://localhost:8080/d1 -u admin:admin > * curl -X POST http://localhost:8080/d2 -u admin:admin > Attempt to copy one item on top of the other: > * curl -F ":operation=copy" -F ":dest=d2" http://localhost:8080/d1 -u > admin:admin > Correctly encounter: 412 "Cannot copy JcrNodeResource, type=nt:unstructured, > path=/d1 to /d2: destination exists" > Attempt to copy one item on top of the other with :replace set to true: > * curl -F ":operation=copy" -F ":dest=d2" -F ":replace=true" > http://localhost:8080/d1 -u admin:admin > This should now succeed, however, it is returning: > 500 javax.jcr.PathNotFoundException: /d2 > and we know for sure /d2 exists! > I think this might be related to changes in the pooling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1281) Copy Move operations dont work.
[ https://issues.apache.org/jira/browse/SLING-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798716#action_12798716 ] Ian Boston commented on SLING-1281: --- Committed patch that uses the newly created item and avoids the save operation. > Copy Move operations dont work. > --- > > Key: SLING-1281 > URL: https://issues.apache.org/jira/browse/SLING-1281 > Project: Sling > Issue Type: Bug >Affects Versions: Servlets Post 2.0.6, JCR Jackrabbit Server 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: Servlets Post 2.0.6 > > Attachments: test-SLING-1281.sh > > > To reproduce: > Create 2 content items: > * curl -X POST http://localhost:8080/d1 -u admin:admin > * curl -X POST http://localhost:8080/d2 -u admin:admin > Attempt to copy one item on top of the other: > * curl -F ":operation=copy" -F ":dest=d2" http://localhost:8080/d1 -u > admin:admin > Correctly encounter: 412 "Cannot copy JcrNodeResource, type=nt:unstructured, > path=/d1 to /d2: destination exists" > Attempt to copy one item on top of the other with :replace set to true: > * curl -F ":operation=copy" -F ":dest=d2" -F ":replace=true" > http://localhost:8080/d1 -u admin:admin > This should now succeed, however, it is returning: > 500 javax.jcr.PathNotFoundException: /d2 > and we know for sure /d2 exists! > I think this might be related to changes in the pooling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1281) Copy Move operations dont work.
[ https://issues.apache.org/jira/browse/SLING-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798830#action_12798830 ] Ian Boston commented on SLING-1281: --- Yes, that appears to be the pattern. There might be more activity between the addNode and the getNode but I think its only setting properties, although that might invoke some extra permissions checks. When this happend in Sakai I noticed that changing the LoginModule from PluggableDefaultLoginModule to DefaultLoginModule in both Sling and Sakai caused the same problem, which is bizarre since that appears to be completely unrelated. > Copy Move operations dont work. > --- > > Key: SLING-1281 > URL: https://issues.apache.org/jira/browse/SLING-1281 > Project: Sling > Issue Type: Bug >Affects Versions: Servlets Post 2.0.6, JCR Jackrabbit Server 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: Servlets Post 2.0.6 > > Attachments: test-SLING-1281.sh > > > To reproduce: > Create 2 content items: > * curl -X POST http://localhost:8080/d1 -u admin:admin > * curl -X POST http://localhost:8080/d2 -u admin:admin > Attempt to copy one item on top of the other: > * curl -F ":operation=copy" -F ":dest=d2" http://localhost:8080/d1 -u > admin:admin > Correctly encounter: 412 "Cannot copy JcrNodeResource, type=nt:unstructured, > path=/d1 to /d2: destination exists" > Attempt to copy one item on top of the other with :replace set to true: > * curl -F ":operation=copy" -F ":dest=d2" -F ":replace=true" > http://localhost:8080/d1 -u admin:admin > This should now succeed, however, it is returning: > 500 javax.jcr.PathNotFoundException: /d2 > and we know for sure /d2 exists! > I think this might be related to changes in the pooling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1237) Odd behavior from jackrabbit-usermanager group.delete
[
https://issues.apache.org/jira/browse/SLING-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800614#action_12800614
]
Ian Boston commented on SLING-1237:
---
There is another side issue here, if the user has been granted permissions to
remove the group because they are a member of the group, the operation of
delete group can only be performed in a single REST operation.
If members are removed in one operation, then the member who has permission to
remove the group is no longer a member and so cant remove the group.
> Odd behavior from jackrabbit-usermanager group.delete
> -
>
> Key: SLING-1237
> URL: https://issues.apache.org/jira/browse/SLING-1237
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Affects Versions: JCR Jackrabbit User Manager 2.0.4
>Reporter: Ray Davis
>
> (This is from a build of rev 889246.)
> Deleting a group which has a member throws an error. Trying to look at the
> group afterwards throws an error. Trying to recreate the group afterward
> throws an error. But then the group seems to have been recreated successfully.
> curl -u admin:admin -F :name=agroup
> http://localhost:8080/system/userManager/group.create.html
> curl -u admin:admin http://localhost:8080/system/userManager/group/agroup.json
> {}
> curl -u admin:admin -F :member=nico
> http://localhost:8080/system/userManager/group/agroup.update.html
> curl -u admin:admin -X POST
> http://localhost:8080/system/userManager/group/agroup.delete.html
> Error while processing /system/userManager/group/agroup
> javax.jcr.ReferentialIntegrityException:
> 901c8411-932e-40b1-bf19-7b675b6dfb81: the node cannot be removed because it
> is still being referenced.
> curl -u admin:admin http://localhost:8080/system/userManager/group/agroup.json
> 404 No resource found
> curl -u admin:admin -F :name=agroup
> http://localhost:8080/system/userManager/group.create.html
> Error while processing /system/userManager/group
> javax.jcr.RepositoryException: Failed to create new group.:
> 901c8411-932e-40b1-bf19-7b675b6dfb81: the node cannot be removed because it
> is still being referenced.: 901c8411-932e-40b1-bf19-7b675b6dfb81: the node
> cannot be removed because it is still being referenced.
> curl -u admin:admin http://localhost:8080/system/userManager/group/agroup.json
> {}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1282) Adminisrative logins depend on password in the code or config
[ https://issues.apache.org/jira/browse/SLING-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800615#action_12800615 ] Ian Boston commented on SLING-1282: --- was discussed here http://markmail.org/thread/ppvsmacmwnrateca > Adminisrative logins depend on password in the code or config > - > > Key: SLING-1282 > URL: https://issues.apache.org/jira/browse/SLING-1282 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR Jackrabbit Server 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: JCR Jackrabbit Server 2.0.6 > > > Administrative logins use SimpleCredentials which means that they have to > have a password. Although this is a configuration parameter changing the > admin password creates some JVM timing difficulties especially when operating > in a cluster. (JVMs would probably need to be restarted with new config > immediately after changing the admin password.) > It would be better to use special credentials to indicate internal logins to > the repository (eg public final class AdministrativeCredentials implements > Credentials) > same is true for Anon/Guest users, although less important. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1290) Concurrent modification exception on startup
[ https://issues.apache.org/jira/browse/SLING-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12802233#action_12802233 ] Ian Boston commented on SLING-1290: --- Since multithreaded reading can happen during startup we need to setFast(true) on the FastTreeMap as soon as its created, rather than after its initialized. This will incur an overhead in GC activity but make the operation multithreaded. Need to check the code to see what is done at the moment. doc on FastTreeMap is at http://commons.apache.org/collections/api-2.1.1/org/apache/commons/collections/FastTreeMap.html > Concurrent modification exception on startup > > > Key: SLING-1290 > URL: https://issues.apache.org/jira/browse/SLING-1290 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR Resource 2.0.6 >Reporter: Carsten Ziegeler > > java.util.ConcurrentModificationException > at > org.apache.commons.collections.FastTreeMap$CollectionView$CollectionViewIterator.hasNext(FastTreeMap.java:745) > at > org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry.getResourceProviders(ResourceProviderEntry.java:547) > at > org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry.getResourceProviders(ResourceProviderEntry.java:529) > at > org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry.access$000(ResourceProviderEntry.java:50) > at > org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry$1.(ResourceProviderEntry.java:167) > at > org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry.listChildren(ResourceProviderEntry.java:142) > at > org.apache.sling.jcr.resource.internal.JcrResourceResolver.listChildren(JcrResourceResolver.java:458) > at > org.apache.sling.servlets.resolver.internal.helper.ResourceCollector.getWeightedResources(ResourceCollector.java:193) > at > org.apache.sling.servlets.resolver.internal.helper.ResourceCollector.getServlets(ResourceCollector.java:173) > at > org.apache.sling.servlets.resolver.internal.SlingServletResolver.getServlet(SlingServletResolver.java:457) > at > org.apache.sling.servlets.resolver.internal.SlingServletResolver.resolveServlet(SlingServletResolver.java:205) > at > org.apache.sling.engine.impl.request.RequestData.initServlet(RequestData.java:216) > at > org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:298) > at > org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:189) > at > org.eclipse.equinox.http.servlet.internal.ServletRegistration.handleRequest(ServletRegistration.java:90) > at > org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:109) > at > org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:75) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.sling.launchpad.base.webapp.SlingServletDelegate.service(SlingServletDelegate.java:276) > at > org.apache.sling.launchpad.webapp.SlingServlet.service(SlingServlet.java:129) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > com.day.crx.launchpad.filters.CRXLaunchpadLicenseFilter.doFilter(CRXLaunchpadLicenseFilter.java:96) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) > at > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) > at java.lang.Thread.run(Thread.java:637) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1290) Concurrent modification exception on startup
[
https://issues.apache.org/jira/browse/SLING-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12802240#action_12802240
]
Ian Boston commented on SLING-1290:
---
setFast(true) is in the constructor, and there are no calls within the
constructor that would cause a reference to "this" to leak out and be used by
another thread prior to setFast(true).
According to the doc, once setFast(true) is called, the FastTreeMap is thread
safe
Looking for the code for CollectionViewIterator.hasNext() I see
public boolean hasNext() {
if (expected != map) {
throw new ConcurrentModificationException();
}
return iterator.hasNext();
}
Ie if the map that was in existence when the iterator was created is changed,
then we get a concurrent modification exception, indicating get() access to the
fast tree map is thread safe, but iterator access is not. This is the same as
TreeMap (Javadoc there warns of the iterator issue)
IIRC the TreeMap was used to maintain an order, and FastTreeMap for thread
safety of read and write operations. There is no ordered ConcurrentHashMap
which doesnt have fast-fail iterators
If we want to solve this, we will need to change all the loops to take a copy
of all values prior to iterating, or keep a readonly copy of the array used for
iterating, updated after each update, taking an atomic reference prior to any
iteration.
WDYT ?
> Concurrent modification exception on startup
>
>
> Key: SLING-1290
> URL: https://issues.apache.org/jira/browse/SLING-1290
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Affects Versions: JCR Resource 2.0.6
>Reporter: Carsten Ziegeler
>
> java.util.ConcurrentModificationException
> at
> org.apache.commons.collections.FastTreeMap$CollectionView$CollectionViewIterator.hasNext(FastTreeMap.java:745)
> at
> org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry.getResourceProviders(ResourceProviderEntry.java:547)
> at
> org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry.getResourceProviders(ResourceProviderEntry.java:529)
> at
> org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry.access$000(ResourceProviderEntry.java:50)
> at
> org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry$1.(ResourceProviderEntry.java:167)
> at
> org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry.listChildren(ResourceProviderEntry.java:142)
> at
> org.apache.sling.jcr.resource.internal.JcrResourceResolver.listChildren(JcrResourceResolver.java:458)
> at
> org.apache.sling.servlets.resolver.internal.helper.ResourceCollector.getWeightedResources(ResourceCollector.java:193)
> at
> org.apache.sling.servlets.resolver.internal.helper.ResourceCollector.getServlets(ResourceCollector.java:173)
> at
> org.apache.sling.servlets.resolver.internal.SlingServletResolver.getServlet(SlingServletResolver.java:457)
> at
> org.apache.sling.servlets.resolver.internal.SlingServletResolver.resolveServlet(SlingServletResolver.java:205)
> at
> org.apache.sling.engine.impl.request.RequestData.initServlet(RequestData.java:216)
> at
> org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:298)
> at
> org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:189)
> at
> org.eclipse.equinox.http.servlet.internal.ServletRegistration.handleRequest(ServletRegistration.java:90)
> at
> org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:109)
> at
> org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:75)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at
> org.apache.sling.launchpad.base.webapp.SlingServletDelegate.service(SlingServletDelegate.java:276)
> at
> org.apache.sling.launchpad.webapp.SlingServlet.service(SlingServlet.java:129)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> com.day.crx.launchpad.filters.CRXLaunchpadLicenseFilter.doFilter(CRXLaunchpadLicenseFilter.java:96)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at
> org.apache.catalina.co
[jira] Commented: (SLING-1308) Node.infinity.json contains risk for DOS.
[ https://issues.apache.org/jira/browse/SLING-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803233#action_12803233 ] Ian Boston commented on SLING-1308: --- Happy to apply this and fix the import orders, but I am going to wait a few hours just in case anyone wants to shout. > Node.infinity.json contains risk for DOS. > - > > Key: SLING-1308 > URL: https://issues.apache.org/jira/browse/SLING-1308 > Project: Sling > Issue Type: Bug > Components: Servlets >Affects Versions: Servlets Get 2.0.8 >Reporter: Simon Gaeremynck >Priority: Critical > Attachments: jsonRenderer.diff > > > As it is now any user can do a node.infinity.json . > If this happens on the root node in a repository with many items, it will > cause the server to slow down (eventually crash?) > I've created a patch confirming the discussion @ > http://markmail.org/search/?q=node.infinity#query:node.infinity+page:1+mid:ugqjyqdz2trfpdkr+state:results -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1290) Concurrent modification exception on startup
[ https://issues.apache.org/jira/browse/SLING-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1280#action_1280 ] Ian Boston commented on SLING-1290: --- I have a fix that uses a copy after modify to ensure the iterator is thread safe. On the basis that the collections will be small and there wont be many updates I think this is ok. Still need the FastTreeMap since gets go directly there. > Concurrent modification exception on startup > > > Key: SLING-1290 > URL: https://issues.apache.org/jira/browse/SLING-1290 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR Resource 2.0.6 >Reporter: Carsten Ziegeler >Assignee: Ian Boston > > java.util.ConcurrentModificationException > at > org.apache.commons.collections.FastTreeMap$CollectionView$CollectionViewIterator.hasNext(FastTreeMap.java:745) > at > org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry.getResourceProviders(ResourceProviderEntry.java:547) > at > org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry.getResourceProviders(ResourceProviderEntry.java:529) > at > org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry.access$000(ResourceProviderEntry.java:50) > at > org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry$1.(ResourceProviderEntry.java:167) > at > org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry.listChildren(ResourceProviderEntry.java:142) > at > org.apache.sling.jcr.resource.internal.JcrResourceResolver.listChildren(JcrResourceResolver.java:458) > at > org.apache.sling.servlets.resolver.internal.helper.ResourceCollector.getWeightedResources(ResourceCollector.java:193) > at > org.apache.sling.servlets.resolver.internal.helper.ResourceCollector.getServlets(ResourceCollector.java:173) > at > org.apache.sling.servlets.resolver.internal.SlingServletResolver.getServlet(SlingServletResolver.java:457) > at > org.apache.sling.servlets.resolver.internal.SlingServletResolver.resolveServlet(SlingServletResolver.java:205) > at > org.apache.sling.engine.impl.request.RequestData.initServlet(RequestData.java:216) > at > org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:298) > at > org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:189) > at > org.eclipse.equinox.http.servlet.internal.ServletRegistration.handleRequest(ServletRegistration.java:90) > at > org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:109) > at > org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:75) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.sling.launchpad.base.webapp.SlingServletDelegate.service(SlingServletDelegate.java:276) > at > org.apache.sling.launchpad.webapp.SlingServlet.service(SlingServlet.java:129) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > com.day.crx.launchpad.filters.CRXLaunchpadLicenseFilter.doFilter(CRXLaunchpadLicenseFilter.java:96) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) > at > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) > at java.lang.Thread.run(Thread.java:637) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-1290) Concurrent modification exception on startup
[ https://issues.apache.org/jira/browse/SLING-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston reassigned SLING-1290: - Assignee: Ian Boston > Concurrent modification exception on startup > > > Key: SLING-1290 > URL: https://issues.apache.org/jira/browse/SLING-1290 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR Resource 2.0.6 >Reporter: Carsten Ziegeler >Assignee: Ian Boston > > java.util.ConcurrentModificationException > at > org.apache.commons.collections.FastTreeMap$CollectionView$CollectionViewIterator.hasNext(FastTreeMap.java:745) > at > org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry.getResourceProviders(ResourceProviderEntry.java:547) > at > org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry.getResourceProviders(ResourceProviderEntry.java:529) > at > org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry.access$000(ResourceProviderEntry.java:50) > at > org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry$1.(ResourceProviderEntry.java:167) > at > org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry.listChildren(ResourceProviderEntry.java:142) > at > org.apache.sling.jcr.resource.internal.JcrResourceResolver.listChildren(JcrResourceResolver.java:458) > at > org.apache.sling.servlets.resolver.internal.helper.ResourceCollector.getWeightedResources(ResourceCollector.java:193) > at > org.apache.sling.servlets.resolver.internal.helper.ResourceCollector.getServlets(ResourceCollector.java:173) > at > org.apache.sling.servlets.resolver.internal.SlingServletResolver.getServlet(SlingServletResolver.java:457) > at > org.apache.sling.servlets.resolver.internal.SlingServletResolver.resolveServlet(SlingServletResolver.java:205) > at > org.apache.sling.engine.impl.request.RequestData.initServlet(RequestData.java:216) > at > org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:298) > at > org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:189) > at > org.eclipse.equinox.http.servlet.internal.ServletRegistration.handleRequest(ServletRegistration.java:90) > at > org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:109) > at > org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:75) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.sling.launchpad.base.webapp.SlingServletDelegate.service(SlingServletDelegate.java:276) > at > org.apache.sling.launchpad.webapp.SlingServlet.service(SlingServlet.java:129) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > com.day.crx.launchpad.filters.CRXLaunchpadLicenseFilter.doFilter(CRXLaunchpadLicenseFilter.java:96) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) > at > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) > at java.lang.Thread.run(Thread.java:637) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1290) Concurrent modification exception on startup
[ https://issues.apache.org/jira/browse/SLING-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston resolved SLING-1290. --- Resolution: Fixed Fix Version/s: JCR Resource 2.0.8 Believed to be fixed, but havent wasn't able to reproduce reliably, or reproduce after fix. > Concurrent modification exception on startup > > > Key: SLING-1290 > URL: https://issues.apache.org/jira/browse/SLING-1290 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR Resource 2.0.6 >Reporter: Carsten Ziegeler >Assignee: Ian Boston > Fix For: JCR Resource 2.0.8 > > > java.util.ConcurrentModificationException > at > org.apache.commons.collections.FastTreeMap$CollectionView$CollectionViewIterator.hasNext(FastTreeMap.java:745) > at > org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry.getResourceProviders(ResourceProviderEntry.java:547) > at > org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry.getResourceProviders(ResourceProviderEntry.java:529) > at > org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry.access$000(ResourceProviderEntry.java:50) > at > org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry$1.(ResourceProviderEntry.java:167) > at > org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry.listChildren(ResourceProviderEntry.java:142) > at > org.apache.sling.jcr.resource.internal.JcrResourceResolver.listChildren(JcrResourceResolver.java:458) > at > org.apache.sling.servlets.resolver.internal.helper.ResourceCollector.getWeightedResources(ResourceCollector.java:193) > at > org.apache.sling.servlets.resolver.internal.helper.ResourceCollector.getServlets(ResourceCollector.java:173) > at > org.apache.sling.servlets.resolver.internal.SlingServletResolver.getServlet(SlingServletResolver.java:457) > at > org.apache.sling.servlets.resolver.internal.SlingServletResolver.resolveServlet(SlingServletResolver.java:205) > at > org.apache.sling.engine.impl.request.RequestData.initServlet(RequestData.java:216) > at > org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:298) > at > org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:189) > at > org.eclipse.equinox.http.servlet.internal.ServletRegistration.handleRequest(ServletRegistration.java:90) > at > org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:109) > at > org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:75) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.sling.launchpad.base.webapp.SlingServletDelegate.service(SlingServletDelegate.java:276) > at > org.apache.sling.launchpad.webapp.SlingServlet.service(SlingServlet.java:129) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > com.day.crx.launchpad.filters.CRXLaunchpadLicenseFilter.doFilter(CRXLaunchpadLicenseFilter.java:96) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) > at > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) > at java.lang.Thread.run(Thread.java:637) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1282) Adminisrative logins depend on password in the code or config
[ https://issues.apache.org/jira/browse/SLING-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803395#action_12803395 ] Ian Boston commented on SLING-1282: --- Uploaded patch set for this to http://codereview.appspot.com/190100 Issues: Jackrabbit binds directly to SImpleCredentials which is final. So I have had to use a wrapped callback handler to intercept requests for the User ID and Impersonation where the final AdministrativeCredentials and AnonCredentials are used. This appears to be perfectly Ok for the UserID, but I am concerned that two things might be broken and not picked up by either integration testing or unit testing Impersonation JAAS based authentication which will further rely on the CallbackHandler mechanisms. If someone has the time, I would appreciate a check as I dont think I should commit as it is. Thanks Ian > Adminisrative logins depend on password in the code or config > - > > Key: SLING-1282 > URL: https://issues.apache.org/jira/browse/SLING-1282 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR Jackrabbit Server 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: JCR Jackrabbit Server 2.0.6 > > > Administrative logins use SimpleCredentials which means that they have to > have a password. Although this is a configuration parameter changing the > admin password creates some JVM timing difficulties especially when operating > in a cluster. (JVMs would probably need to be restarted with new config > immediately after changing the admin password.) > It would be better to use special credentials to indicate internal logins to > the repository (eg public final class AdministrativeCredentials implements > Credentials) > same is true for Anon/Guest users, although less important. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-1308) Node.infinity.json contains risk for DOS.
[ https://issues.apache.org/jira/browse/SLING-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston reassigned SLING-1308: - Assignee: Ian Boston > Node.infinity.json contains risk for DOS. > - > > Key: SLING-1308 > URL: https://issues.apache.org/jira/browse/SLING-1308 > Project: Sling > Issue Type: Bug > Components: Servlets >Affects Versions: Servlets Get 2.0.8 >Reporter: Simon Gaeremynck >Assignee: Ian Boston >Priority: Critical > Attachments: jsonRenderer.diff, jsonRenderer.diff > > > As it is now any user can do a node.infinity.json . > If this happens on the root node in a repository with many items, it will > cause the server to slow down (eventually crash?) > I've created a patch confirming the discussion @ > http://markmail.org/search/?q=node.infinity#query:node.infinity+page:1+mid:ugqjyqdz2trfpdkr+state:results -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1308) Node.infinity.json contains risk for DOS.
[ https://issues.apache.org/jira/browse/SLING-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803510#action_12803510 ] Ian Boston commented on SLING-1308: --- Patch applies ok and the integration tests passes. However, I have reverted the changes to the Sling API to eliminate the need to depend on a later version of the API. Also there was a license header missing, added in. Other than that LGTM, I will go and find the doc and update that as well. > Node.infinity.json contains risk for DOS. > - > > Key: SLING-1308 > URL: https://issues.apache.org/jira/browse/SLING-1308 > Project: Sling > Issue Type: Bug > Components: Servlets >Affects Versions: Servlets Get 2.0.8 >Reporter: Simon Gaeremynck >Assignee: Ian Boston >Priority: Critical > Attachments: jsonRenderer.diff, jsonRenderer.diff > > > As it is now any user can do a node.infinity.json . > If this happens on the root node in a repository with many items, it will > cause the server to slow down (eventually crash?) > I've created a patch confirming the discussion @ > http://markmail.org/search/?q=node.infinity#query:node.infinity+page:1+mid:ugqjyqdz2trfpdkr+state:results -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1282) Adminisrative logins depend on password in the code or config
[ https://issues.apache.org/jira/browse/SLING-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804242#action_12804242 ] Ian Boston commented on SLING-1282: --- That makes sense, I will modify, test and commit. > Adminisrative logins depend on password in the code or config > - > > Key: SLING-1282 > URL: https://issues.apache.org/jira/browse/SLING-1282 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR Jackrabbit Server 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: JCR Jackrabbit Server 2.0.6 > > > Administrative logins use SimpleCredentials which means that they have to > have a password. Although this is a configuration parameter changing the > admin password creates some JVM timing difficulties especially when operating > in a cluster. (JVMs would probably need to be restarted with new config > immediately after changing the admin password.) > It would be better to use special credentials to indicate internal logins to > the repository (eg public final class AdministrativeCredentials implements > Credentials) > same is true for Anon/Guest users, although less important. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1282) Adminisrative logins depend on password in the code or config
[ https://issues.apache.org/jira/browse/SLING-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston resolved SLING-1282. --- Resolution: Fixed Fixed, Administrative and Anon logins no longer rely on the configured passwords allowing those password to be changed by the UserManager without requiring a full restart. > Adminisrative logins depend on password in the code or config > - > > Key: SLING-1282 > URL: https://issues.apache.org/jira/browse/SLING-1282 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR Jackrabbit Server 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: JCR Jackrabbit Server 2.0.6 > > > Administrative logins use SimpleCredentials which means that they have to > have a password. Although this is a configuration parameter changing the > admin password creates some JVM timing difficulties especially when operating > in a cluster. (JVMs would probably need to be restarted with new config > immediately after changing the admin password.) > It would be better to use special credentials to indicate internal logins to > the repository (eg public final class AdministrativeCredentials implements > Credentials) > same is true for Anon/Guest users, although less important. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1312) Repository wont start due to login failure.
Repository wont start due to login failure. --- Key: SLING-1312 URL: https://issues.apache.org/jira/browse/SLING-1312 Project: Sling Issue Type: Bug Affects Versions: JCR Jackrabbit Server 2.0.6 Reporter: Ian Boston Assignee: Ian Boston Priority: Blocker Almost certainly related to SLING-1282 Will fix 25.01.2010 09:03:11.067 *INFO* [SCR Component Actor] org.apache.sling.jcr.jackrabbit.server pingAndCheck; loginAdministrative failed (javax.jcr.LoginException) javax.jcr.LoginException at org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1407) at org.apache.sling.jcr.base.internal.SessionPool.acquireSession(SessionPool.java:270) at org.apache.sling.jcr.base.internal.SessionPoolManager.login(SessionPoolManager.java:99) at org.apache.sling.jcr.base.AbstractSlingRepository.login(AbstractSlingRepository.java:240) at org.apache.sling.jcr.base.AbstractSlingRepository.loginAdministrative(AbstractSlingRepository.java:206) at org.apache.sling.jcr.base.AbstractSlingRepository.pingAndCheck(AbstractSlingRepository.java:506) at org.apache.sling.jcr.base.AbstractSlingRepository.startRepository(AbstractSlingRepository.java:814) at org.apache.sling.jcr.base.AbstractSlingRepository.activate(AbstractSlingRepository.java:629) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:213) at org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:38) at org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:542) at org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:434) at org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:138) at org.apache.felix.scr.impl.manager.ImmediateComponentManager.createImplementationObject(ImmediateComponentManager.java:226) at org.apache.felix.scr.impl.manager.ImmediateComponentManager.createComponent(ImmediateComponentManager.java:118) at org.apache.felix.scr.impl.manager.AbstractComponentManager$Unsatisfied.activate(AbstractComponentManager.java:991) at org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:298) at org.apache.felix.scr.impl.manager.AbstractComponentManager$1.doRun(AbstractComponentManager.java:138) at org.apache.felix.scr.impl.ComponentActivatorTask.run(ComponentActivatorTask.java:67) at org.apache.felix.scr.impl.ComponentActorThread.run(ComponentActorThread.java:96) at java.lang.Thread.run(Thread.java:637) Caused by: javax.security.auth.login.FailedLoginException at org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.authenticate(AbstractLoginModule.java:427) at org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.login(AbstractLoginModule.java:289) at org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:72) at org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1392) ... 24 more javax.security.auth.login.FailedLoginException at org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.authenticate(AbstractLoginModule.java:427) at org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.login(AbstractLoginModule.java:289) at org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:72) at org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1392) at org.apache.sling.jcr.base.internal.SessionPool.acquireSession(SessionPool.java:270) at org.apache.sling.jcr.base.internal.SessionPoolManager.login(SessionPoolManager.java:99) at org.apache.sling.jcr.base.AbstractSlingRepository.login(AbstractSlingRepository.java:240) at org.apache.sling.jcr.base.AbstractSlingRepository.loginAdministrative(AbstractSlingRepository.java:206) at org.apache.sling.jcr.base.AbstractSlingRepository.pingAndCheck(AbstractSlingRepository.java:506) at org.apache.sling.jcr.base.AbstractSlingRepository.startRepository(AbstractSlingRepository.java:814) at org.apache.sling.jcr.base.AbstractSlingRepository.activate(AbstractSlingRepository.java:629) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[jira] Commented: (SLING-1312) Repository wont start due to login failure.
[ https://issues.apache.org/jira/browse/SLING-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804453#action_12804453 ] Ian Boston commented on SLING-1312: --- Line numbers in the trace back are 1 line out for the AbstractSlingRepository, eg org.apache.sling.jcr.base.AbstractSlingRepository.loginAdministrative(AbstractSlingRepository.java:206) should have been at 205. Indicating that the code running is not the source code. Even so, if its the older code there should have been SimpleCredentials which should have worked. Still checking. > Repository wont start due to login failure. > --- > > Key: SLING-1312 > URL: https://issues.apache.org/jira/browse/SLING-1312 > Project: Sling > Issue Type: Bug >Affects Versions: JCR Jackrabbit Server 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston >Priority: Blocker > > Almost certainly related to SLING-1282 > Will fix > 25.01.2010 09:03:11.067 *INFO* [SCR Component Actor] > org.apache.sling.jcr.jackrabbit.server pingAndCheck; loginAdministrative > failed (javax.jcr.LoginException) javax.jcr.LoginException > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1407) > at > org.apache.sling.jcr.base.internal.SessionPool.acquireSession(SessionPool.java:270) > at > org.apache.sling.jcr.base.internal.SessionPoolManager.login(SessionPoolManager.java:99) > at > org.apache.sling.jcr.base.AbstractSlingRepository.login(AbstractSlingRepository.java:240) > at > org.apache.sling.jcr.base.AbstractSlingRepository.loginAdministrative(AbstractSlingRepository.java:206) > at > org.apache.sling.jcr.base.AbstractSlingRepository.pingAndCheck(AbstractSlingRepository.java:506) > at > org.apache.sling.jcr.base.AbstractSlingRepository.startRepository(AbstractSlingRepository.java:814) > at > org.apache.sling.jcr.base.AbstractSlingRepository.activate(AbstractSlingRepository.java:629) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:213) > at > org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:38) > at > org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:542) > at > org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:434) > at > org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:138) > at > org.apache.felix.scr.impl.manager.ImmediateComponentManager.createImplementationObject(ImmediateComponentManager.java:226) > at > org.apache.felix.scr.impl.manager.ImmediateComponentManager.createComponent(ImmediateComponentManager.java:118) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager$Unsatisfied.activate(AbstractComponentManager.java:991) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:298) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager$1.doRun(AbstractComponentManager.java:138) > at > org.apache.felix.scr.impl.ComponentActivatorTask.run(ComponentActivatorTask.java:67) > at > org.apache.felix.scr.impl.ComponentActorThread.run(ComponentActorThread.java:96) > at java.lang.Thread.run(Thread.java:637) > Caused by: javax.security.auth.login.FailedLoginException > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.authenticate(AbstractLoginModule.java:427) > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.login(AbstractLoginModule.java:289) > at > org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:72) > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1392) > ... 24 more > javax.security.auth.login.FailedLoginException > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.authenticate(AbstractLoginModule.java:427) > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.login(AbstractLoginModule.java:289) > at > org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:72) > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1392) > at > org.apache.sling.jcr.base.internal.SessionPool.acquireSession(SessionPool.java:270) > at > org.apache.sling.jcr.base.internal.SessionPoolManager.login(Session
[jira] Commented: (SLING-1312) Repository wont start due to login failure.
[ https://issues.apache.org/jira/browse/SLING-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804465#action_12804465 ] Ian Boston commented on SLING-1312: --- Yes, that fixes that problem, but impersonate is now failing. I think our integration tests are not pulling from locally built artifacts (at least for me) since I did full builds before committing, and there were no issues. Perhaps I should revert the changes under SLING-1281 ? > Repository wont start due to login failure. > --- > > Key: SLING-1312 > URL: https://issues.apache.org/jira/browse/SLING-1312 > Project: Sling > Issue Type: Bug >Affects Versions: JCR Jackrabbit Server 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston >Priority: Blocker > > Almost certainly related to SLING-1282 > Will fix > 25.01.2010 09:03:11.067 *INFO* [SCR Component Actor] > org.apache.sling.jcr.jackrabbit.server pingAndCheck; loginAdministrative > failed (javax.jcr.LoginException) javax.jcr.LoginException > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1407) > at > org.apache.sling.jcr.base.internal.SessionPool.acquireSession(SessionPool.java:270) > at > org.apache.sling.jcr.base.internal.SessionPoolManager.login(SessionPoolManager.java:99) > at > org.apache.sling.jcr.base.AbstractSlingRepository.login(AbstractSlingRepository.java:240) > at > org.apache.sling.jcr.base.AbstractSlingRepository.loginAdministrative(AbstractSlingRepository.java:206) > at > org.apache.sling.jcr.base.AbstractSlingRepository.pingAndCheck(AbstractSlingRepository.java:506) > at > org.apache.sling.jcr.base.AbstractSlingRepository.startRepository(AbstractSlingRepository.java:814) > at > org.apache.sling.jcr.base.AbstractSlingRepository.activate(AbstractSlingRepository.java:629) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:213) > at > org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:38) > at > org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:542) > at > org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:434) > at > org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:138) > at > org.apache.felix.scr.impl.manager.ImmediateComponentManager.createImplementationObject(ImmediateComponentManager.java:226) > at > org.apache.felix.scr.impl.manager.ImmediateComponentManager.createComponent(ImmediateComponentManager.java:118) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager$Unsatisfied.activate(AbstractComponentManager.java:991) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:298) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager$1.doRun(AbstractComponentManager.java:138) > at > org.apache.felix.scr.impl.ComponentActivatorTask.run(ComponentActivatorTask.java:67) > at > org.apache.felix.scr.impl.ComponentActorThread.run(ComponentActorThread.java:96) > at java.lang.Thread.run(Thread.java:637) > Caused by: javax.security.auth.login.FailedLoginException > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.authenticate(AbstractLoginModule.java:427) > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.login(AbstractLoginModule.java:289) > at > org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:72) > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1392) > ... 24 more > javax.security.auth.login.FailedLoginException > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.authenticate(AbstractLoginModule.java:427) > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.login(AbstractLoginModule.java:289) > at > org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:72) > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1392) > at > org.apache.sling.jcr.base.internal.SessionPool.acquireSession(SessionPool.java:270) > at > org.apache.sling.jcr.base.internal.SessionPoolManager.login(SessionPoolManager.java:99) > at > org.apache.sling.jcr.base.AbstractSlingRepository.login(AbstractSlingRe
[jira] Commented: (SLING-1312) Repository wont start due to login failure.
[ https://issues.apache.org/jira/browse/SLING-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804469#action_12804469 ] Ian Boston commented on SLING-1312: --- The AdministrativeCredentials was not returning and AdminPrincipal causing impersonation to fail for the admin user. > Repository wont start due to login failure. > --- > > Key: SLING-1312 > URL: https://issues.apache.org/jira/browse/SLING-1312 > Project: Sling > Issue Type: Bug >Affects Versions: JCR Jackrabbit Server 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston >Priority: Blocker > > Almost certainly related to SLING-1282 > Will fix > 25.01.2010 09:03:11.067 *INFO* [SCR Component Actor] > org.apache.sling.jcr.jackrabbit.server pingAndCheck; loginAdministrative > failed (javax.jcr.LoginException) javax.jcr.LoginException > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1407) > at > org.apache.sling.jcr.base.internal.SessionPool.acquireSession(SessionPool.java:270) > at > org.apache.sling.jcr.base.internal.SessionPoolManager.login(SessionPoolManager.java:99) > at > org.apache.sling.jcr.base.AbstractSlingRepository.login(AbstractSlingRepository.java:240) > at > org.apache.sling.jcr.base.AbstractSlingRepository.loginAdministrative(AbstractSlingRepository.java:206) > at > org.apache.sling.jcr.base.AbstractSlingRepository.pingAndCheck(AbstractSlingRepository.java:506) > at > org.apache.sling.jcr.base.AbstractSlingRepository.startRepository(AbstractSlingRepository.java:814) > at > org.apache.sling.jcr.base.AbstractSlingRepository.activate(AbstractSlingRepository.java:629) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:213) > at > org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:38) > at > org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:542) > at > org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:434) > at > org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:138) > at > org.apache.felix.scr.impl.manager.ImmediateComponentManager.createImplementationObject(ImmediateComponentManager.java:226) > at > org.apache.felix.scr.impl.manager.ImmediateComponentManager.createComponent(ImmediateComponentManager.java:118) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager$Unsatisfied.activate(AbstractComponentManager.java:991) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:298) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager$1.doRun(AbstractComponentManager.java:138) > at > org.apache.felix.scr.impl.ComponentActivatorTask.run(ComponentActivatorTask.java:67) > at > org.apache.felix.scr.impl.ComponentActorThread.run(ComponentActorThread.java:96) > at java.lang.Thread.run(Thread.java:637) > Caused by: javax.security.auth.login.FailedLoginException > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.authenticate(AbstractLoginModule.java:427) > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.login(AbstractLoginModule.java:289) > at > org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:72) > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1392) > ... 24 more > javax.security.auth.login.FailedLoginException > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.authenticate(AbstractLoginModule.java:427) > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.login(AbstractLoginModule.java:289) > at > org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:72) > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1392) > at > org.apache.sling.jcr.base.internal.SessionPool.acquireSession(SessionPool.java:270) > at > org.apache.sling.jcr.base.internal.SessionPoolManager.login(SessionPoolManager.java:99) > at > org.apache.sling.jcr.base.AbstractSlingRepository.login(AbstractSlingRepository.java:240) > at > org.apache.sling.jcr.base.AbstractSlingRepository.loginAdministrative(AbstractSlingRepository.java:206) > at > org.apache.slin
[jira] Issue Comment Edited: (SLING-1312) Repository wont start due to login failure.
[ https://issues.apache.org/jira/browse/SLING-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804465#action_12804465 ] Ian Boston edited comment on SLING-1312 at 1/25/10 10:31 AM: - Yes, that fixes that problem, but impersonate is now failing. I think our integration tests are not pulling from locally built artifacts (at least for me) since I did full builds before committing, and there were no issues. Perhaps I should revert the changes under SLING-1282 ? was (Author: ianeboston): Yes, that fixes that problem, but impersonate is now failing. I think our integration tests are not pulling from locally built artifacts (at least for me) since I did full builds before committing, and there were no issues. Perhaps I should revert the changes under SLING-1281 ? > Repository wont start due to login failure. > --- > > Key: SLING-1312 > URL: https://issues.apache.org/jira/browse/SLING-1312 > Project: Sling > Issue Type: Bug >Affects Versions: JCR Jackrabbit Server 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston >Priority: Blocker > > Almost certainly related to SLING-1282 > Will fix > 25.01.2010 09:03:11.067 *INFO* [SCR Component Actor] > org.apache.sling.jcr.jackrabbit.server pingAndCheck; loginAdministrative > failed (javax.jcr.LoginException) javax.jcr.LoginException > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1407) > at > org.apache.sling.jcr.base.internal.SessionPool.acquireSession(SessionPool.java:270) > at > org.apache.sling.jcr.base.internal.SessionPoolManager.login(SessionPoolManager.java:99) > at > org.apache.sling.jcr.base.AbstractSlingRepository.login(AbstractSlingRepository.java:240) > at > org.apache.sling.jcr.base.AbstractSlingRepository.loginAdministrative(AbstractSlingRepository.java:206) > at > org.apache.sling.jcr.base.AbstractSlingRepository.pingAndCheck(AbstractSlingRepository.java:506) > at > org.apache.sling.jcr.base.AbstractSlingRepository.startRepository(AbstractSlingRepository.java:814) > at > org.apache.sling.jcr.base.AbstractSlingRepository.activate(AbstractSlingRepository.java:629) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:213) > at > org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:38) > at > org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:542) > at > org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:434) > at > org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:138) > at > org.apache.felix.scr.impl.manager.ImmediateComponentManager.createImplementationObject(ImmediateComponentManager.java:226) > at > org.apache.felix.scr.impl.manager.ImmediateComponentManager.createComponent(ImmediateComponentManager.java:118) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager$Unsatisfied.activate(AbstractComponentManager.java:991) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:298) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager$1.doRun(AbstractComponentManager.java:138) > at > org.apache.felix.scr.impl.ComponentActivatorTask.run(ComponentActivatorTask.java:67) > at > org.apache.felix.scr.impl.ComponentActorThread.run(ComponentActorThread.java:96) > at java.lang.Thread.run(Thread.java:637) > Caused by: javax.security.auth.login.FailedLoginException > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.authenticate(AbstractLoginModule.java:427) > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.login(AbstractLoginModule.java:289) > at > org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:72) > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1392) > ... 24 more > javax.security.auth.login.FailedLoginException > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.authenticate(AbstractLoginModule.java:427) > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.login(AbstractLoginModule.java:289) > at > org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:72)
[jira] Issue Comment Edited: (SLING-1312) Repository wont start due to login failure.
[ https://issues.apache.org/jira/browse/SLING-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804465#action_12804465 ] Ian Boston edited comment on SLING-1312 at 1/25/10 10:31 AM: - Yes, that fixes that problem, but impersonate is now failing. I think our integration tests are not pulling from locally built artifacts (at least for me) since I did full builds before committing, and there were no issues. Perhaps I should revert the changes under SLING-1282 ? was (Author: ianeboston): Yes, that fixes that problem, but impersonate is now failing. I think our integration tests are not pulling from locally built artifacts (at least for me) since I did full builds before committing, and there were no issues. Perhaps I should revert the changes under SLING-1281 ? > Repository wont start due to login failure. > --- > > Key: SLING-1312 > URL: https://issues.apache.org/jira/browse/SLING-1312 > Project: Sling > Issue Type: Bug >Affects Versions: JCR Jackrabbit Server 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston >Priority: Blocker > > Almost certainly related to SLING-1282 > Will fix > 25.01.2010 09:03:11.067 *INFO* [SCR Component Actor] > org.apache.sling.jcr.jackrabbit.server pingAndCheck; loginAdministrative > failed (javax.jcr.LoginException) javax.jcr.LoginException > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1407) > at > org.apache.sling.jcr.base.internal.SessionPool.acquireSession(SessionPool.java:270) > at > org.apache.sling.jcr.base.internal.SessionPoolManager.login(SessionPoolManager.java:99) > at > org.apache.sling.jcr.base.AbstractSlingRepository.login(AbstractSlingRepository.java:240) > at > org.apache.sling.jcr.base.AbstractSlingRepository.loginAdministrative(AbstractSlingRepository.java:206) > at > org.apache.sling.jcr.base.AbstractSlingRepository.pingAndCheck(AbstractSlingRepository.java:506) > at > org.apache.sling.jcr.base.AbstractSlingRepository.startRepository(AbstractSlingRepository.java:814) > at > org.apache.sling.jcr.base.AbstractSlingRepository.activate(AbstractSlingRepository.java:629) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:213) > at > org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:38) > at > org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:542) > at > org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:434) > at > org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:138) > at > org.apache.felix.scr.impl.manager.ImmediateComponentManager.createImplementationObject(ImmediateComponentManager.java:226) > at > org.apache.felix.scr.impl.manager.ImmediateComponentManager.createComponent(ImmediateComponentManager.java:118) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager$Unsatisfied.activate(AbstractComponentManager.java:991) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:298) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager$1.doRun(AbstractComponentManager.java:138) > at > org.apache.felix.scr.impl.ComponentActivatorTask.run(ComponentActivatorTask.java:67) > at > org.apache.felix.scr.impl.ComponentActorThread.run(ComponentActorThread.java:96) > at java.lang.Thread.run(Thread.java:637) > Caused by: javax.security.auth.login.FailedLoginException > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.authenticate(AbstractLoginModule.java:427) > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.login(AbstractLoginModule.java:289) > at > org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:72) > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1392) > ... 24 more > javax.security.auth.login.FailedLoginException > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.authenticate(AbstractLoginModule.java:427) > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.login(AbstractLoginModule.java:289) > at > org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:72)
[jira] Commented: (SLING-1312) Repository wont start due to login failure.
[ https://issues.apache.org/jira/browse/SLING-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804489#action_12804489 ] Ian Boston commented on SLING-1312: --- The Subject does not contain the correct set of principals. Rather than laving trunk unusable, I am going to revert the changes for SLING-1282, reopen that issue and close this one. > Repository wont start due to login failure. > --- > > Key: SLING-1312 > URL: https://issues.apache.org/jira/browse/SLING-1312 > Project: Sling > Issue Type: Bug >Affects Versions: JCR Jackrabbit Server 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston >Priority: Blocker > > Almost certainly related to SLING-1282 > Will fix > 25.01.2010 09:03:11.067 *INFO* [SCR Component Actor] > org.apache.sling.jcr.jackrabbit.server pingAndCheck; loginAdministrative > failed (javax.jcr.LoginException) javax.jcr.LoginException > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1407) > at > org.apache.sling.jcr.base.internal.SessionPool.acquireSession(SessionPool.java:270) > at > org.apache.sling.jcr.base.internal.SessionPoolManager.login(SessionPoolManager.java:99) > at > org.apache.sling.jcr.base.AbstractSlingRepository.login(AbstractSlingRepository.java:240) > at > org.apache.sling.jcr.base.AbstractSlingRepository.loginAdministrative(AbstractSlingRepository.java:206) > at > org.apache.sling.jcr.base.AbstractSlingRepository.pingAndCheck(AbstractSlingRepository.java:506) > at > org.apache.sling.jcr.base.AbstractSlingRepository.startRepository(AbstractSlingRepository.java:814) > at > org.apache.sling.jcr.base.AbstractSlingRepository.activate(AbstractSlingRepository.java:629) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:213) > at > org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:38) > at > org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:542) > at > org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:434) > at > org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:138) > at > org.apache.felix.scr.impl.manager.ImmediateComponentManager.createImplementationObject(ImmediateComponentManager.java:226) > at > org.apache.felix.scr.impl.manager.ImmediateComponentManager.createComponent(ImmediateComponentManager.java:118) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager$Unsatisfied.activate(AbstractComponentManager.java:991) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:298) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager$1.doRun(AbstractComponentManager.java:138) > at > org.apache.felix.scr.impl.ComponentActivatorTask.run(ComponentActivatorTask.java:67) > at > org.apache.felix.scr.impl.ComponentActorThread.run(ComponentActorThread.java:96) > at java.lang.Thread.run(Thread.java:637) > Caused by: javax.security.auth.login.FailedLoginException > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.authenticate(AbstractLoginModule.java:427) > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.login(AbstractLoginModule.java:289) > at > org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:72) > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1392) > ... 24 more > javax.security.auth.login.FailedLoginException > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.authenticate(AbstractLoginModule.java:427) > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.login(AbstractLoginModule.java:289) > at > org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:72) > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1392) > at > org.apache.sling.jcr.base.internal.SessionPool.acquireSession(SessionPool.java:270) > at > org.apache.sling.jcr.base.internal.SessionPoolManager.login(SessionPoolManager.java:99) > at > org.apache.sling.jcr.base.AbstractSlingRepository.login(AbstractSlingRepository.java:240) > at > org.apache.sling.jcr.base.AbstractSlingRepository.loginAdministrati
[jira] Reopened: (SLING-1282) Adminisrative logins depend on password in the code or config
[ https://issues.apache.org/jira/browse/SLING-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston reopened SLING-1282: --- Problems exist with impersonation, reverted all changes and re-opened. > Adminisrative logins depend on password in the code or config > - > > Key: SLING-1282 > URL: https://issues.apache.org/jira/browse/SLING-1282 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR Jackrabbit Server 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: JCR Jackrabbit Server 2.0.6 > > > Administrative logins use SimpleCredentials which means that they have to > have a password. Although this is a configuration parameter changing the > admin password creates some JVM timing difficulties especially when operating > in a cluster. (JVMs would probably need to be restarted with new config > immediately after changing the admin password.) > It would be better to use special credentials to indicate internal logins to > the repository (eg public final class AdministrativeCredentials implements > Credentials) > same is true for Anon/Guest users, although less important. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1312) Repository wont start due to login failure.
[ https://issues.apache.org/jira/browse/SLING-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston resolved SLING-1312. --- Resolution: Fixed Fix Version/s: JCR Jackrabbit Server 2.0.6 Pushed revert to remove SLING-1282, fixing this blocker, re-opened SLING-1282 > Repository wont start due to login failure. > --- > > Key: SLING-1312 > URL: https://issues.apache.org/jira/browse/SLING-1312 > Project: Sling > Issue Type: Bug >Affects Versions: JCR Jackrabbit Server 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston >Priority: Blocker > Fix For: JCR Jackrabbit Server 2.0.6 > > > Almost certainly related to SLING-1282 > Will fix > 25.01.2010 09:03:11.067 *INFO* [SCR Component Actor] > org.apache.sling.jcr.jackrabbit.server pingAndCheck; loginAdministrative > failed (javax.jcr.LoginException) javax.jcr.LoginException > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1407) > at > org.apache.sling.jcr.base.internal.SessionPool.acquireSession(SessionPool.java:270) > at > org.apache.sling.jcr.base.internal.SessionPoolManager.login(SessionPoolManager.java:99) > at > org.apache.sling.jcr.base.AbstractSlingRepository.login(AbstractSlingRepository.java:240) > at > org.apache.sling.jcr.base.AbstractSlingRepository.loginAdministrative(AbstractSlingRepository.java:206) > at > org.apache.sling.jcr.base.AbstractSlingRepository.pingAndCheck(AbstractSlingRepository.java:506) > at > org.apache.sling.jcr.base.AbstractSlingRepository.startRepository(AbstractSlingRepository.java:814) > at > org.apache.sling.jcr.base.AbstractSlingRepository.activate(AbstractSlingRepository.java:629) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:213) > at > org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:38) > at > org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:542) > at > org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:434) > at > org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:138) > at > org.apache.felix.scr.impl.manager.ImmediateComponentManager.createImplementationObject(ImmediateComponentManager.java:226) > at > org.apache.felix.scr.impl.manager.ImmediateComponentManager.createComponent(ImmediateComponentManager.java:118) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager$Unsatisfied.activate(AbstractComponentManager.java:991) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:298) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager$1.doRun(AbstractComponentManager.java:138) > at > org.apache.felix.scr.impl.ComponentActivatorTask.run(ComponentActivatorTask.java:67) > at > org.apache.felix.scr.impl.ComponentActorThread.run(ComponentActorThread.java:96) > at java.lang.Thread.run(Thread.java:637) > Caused by: javax.security.auth.login.FailedLoginException > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.authenticate(AbstractLoginModule.java:427) > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.login(AbstractLoginModule.java:289) > at > org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:72) > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1392) > ... 24 more > javax.security.auth.login.FailedLoginException > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.authenticate(AbstractLoginModule.java:427) > at > org.apache.jackrabbit.core.security.authentication.AbstractLoginModule.login(AbstractLoginModule.java:289) > at > org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:72) > at > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1392) > at > org.apache.sling.jcr.base.internal.SessionPool.acquireSession(SessionPool.java:270) > at > org.apache.sling.jcr.base.internal.SessionPoolManager.login(SessionPoolManager.java:99) > at > org.apache.sling.jcr.base.AbstractSlingRepository.login(AbstractSlingRepository.java:240) > at > org.apache.sling.jcr.base.AbstractSlingRepository.loginAdministrative(AbstractSlingRepository.java:20
[jira] Resolved: (SLING-1282) Adminisrative logins depend on password in the code or config
[ https://issues.apache.org/jira/browse/SLING-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston resolved SLING-1282. --- Resolution: Fixed Fixed problems with impersonation. > Adminisrative logins depend on password in the code or config > - > > Key: SLING-1282 > URL: https://issues.apache.org/jira/browse/SLING-1282 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR Jackrabbit Server 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: JCR Jackrabbit Server 2.0.6 > > > Administrative logins use SimpleCredentials which means that they have to > have a password. Although this is a configuration parameter changing the > admin password creates some JVM timing difficulties especially when operating > in a cluster. (JVMs would probably need to be restarted with new config > immediately after changing the admin password.) > It would be better to use special credentials to indicate internal logins to > the repository (eg public final class AdministrativeCredentials implements > Credentials) > same is true for Anon/Guest users, although less important. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1340) TRACE is supported and probably should not be by default
TRACE is supported and probably should not be by default Key: SLING-1340 URL: https://issues.apache.org/jira/browse/SLING-1340 Project: Sling Issue Type: Bug Components: Engine Affects Versions: Engine 2.0.6 Reporter: Ian Boston Fix For: Engine 2.1.0 A per httpd, TRACE should be off by default. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1116) FORM Based Authentication
[
https://issues.apache.org/jira/browse/SLING-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12828057#action_12828057
]
Ian Boston commented on SLING-1116:
---
One comment that might be relevant:
I notice that the hash in the cookie is of the form
md5(remoteAddress:path):md5(userId:authRealmsha1({sha1}userPassword))
which makes the cookie static for a user from an address which might be a proxy
address, I which case the cookie is susceptible to capture and reuse.,
remove the remote_address and it effectively becomes a clear text password in
http headers with every request.
I also assumes that Jackrabbit has access to the password, which in the case of
a LoginModulePlugin is not the case.
In a slightly different senario, were we are using a SSO system to authenticate
users we need to have secure cookies to track user identity against each
request and we have used
sha1(expirytime:securetoken:userID)@securetokennumber,expiryt...@userid as the
cookie, where expiry time is the epoch when the cookie becomes invalid,
securetoken number comes for a circular buffer to securetokens, identified by
securetokennumber, that buffer completely refreshing after 2.5 times the TTL on
the cookie. Documented in more detail at [1], implemented at [2].
The approach isn't totally secure (nothing is), and still needs to have the
whole server operating over ssl, but the tokens do expire. The downside is that
the circular buffer of secure tokens needs to be distributed in a cluster, and
persisted, however 5x20 bytes changing every 10 minutes shouldn't be too hard
to distribute.
Also if you want to avoid having to manage special Credentials you might
consider using SimpleCredentials with a special attribute class as this wont
require JAAS style callbacks to get round the strong JR->SimpleCredentials
bindings.
1
http://confluence.sakaiproject.org/display/KERNDOC/KERN-579+Trusted+Authentication
(scroll to the bit on Cookies)
2
http://github.com/ieb/open-experiments/tree/master/slingtests/osgikernel/bundles/trustedauth/
> FORM Based Authentication
> -
>
> Key: SLING-1116
> URL: https://issues.apache.org/jira/browse/SLING-1116
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
>Reporter: Eric Norman
>Assignee: Felix Meschberger
> Attachments: org.apache.sling.cookieauth.zip,
> org.apache.sling.sessionauth.zip, SLING_1116_jackrabbit_server_patch.txt,
> updated_org.apache.sling.cookieauth.zip
>
>
> This is a new bundle that provides an implementation of forms based
> authentication for sling.
> The login/logout servlets from the org.apache.sling.commons.auth are used.
> The AuthenticationHandler will use http basic auth credentials if they are on
> the request, otherwise it will use the user/pwd posted from the login form.
> The login form html is generated by a set of scripts
> 1. login.html.esp - full login page (includes login_body.html.esp for the
> form markup)
> 2. login_body.html.esp - just the login form, which may be useful for
> drawing the login form for an ajax context
> 3. loginError.html.esp - full login-error page
> 4. loginError_body.html.esp - just the login-error form, for login error in
> ajax context
> The above scripts are included as bundle-resources @
> /libs/sling/servlet/default
> The bundle also has a couple of test scripts to show some examples of usage:
> 1. loginTest.html.esp - shows who is logged in and links to login or logout
> 2. loginTest2.html.esp - shows how a script can check permissions and show a
> login page if the anonymous user doesn't have permission to see the page,
> Some examples of usage are:
> 1. http://host:port/path/to/node.login.html - show the login page and then
> goto http://host:port/path/to/node after authenticated
> 2. http://host:port/path/to/node.login.html?s=.edit.html - show the login
> page and then goto http://host:port/path/to/node.edit.html after
> authenticated
> 3. http://host:port/system/sling/logout - invalidate the session and switch
> back to anonymous user
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1116) FORM Based Authentication
[ https://issues.apache.org/jira/browse/SLING-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12828213#action_12828213 ] Ian Boston commented on SLING-1116: --- Your right I should be using HMAC, but I am finding it very slow ~ 100ms compared to 67ns for a SHA1 hash. Every request needs to be decoded. This is on JDK 16. on OSX using hmacSHA1 with pre generated key, any ideas ? > FORM Based Authentication > - > > Key: SLING-1116 > URL: https://issues.apache.org/jira/browse/SLING-1116 > Project: Sling > Issue Type: New Feature > Components: Extensions >Reporter: Eric Norman >Assignee: Felix Meschberger > Attachments: org.apache.sling.cookieauth.zip, > org.apache.sling.sessionauth.zip, SLING_1116_jackrabbit_server_patch.txt, > updated_org.apache.sling.cookieauth.zip > > > This is a new bundle that provides an implementation of forms based > authentication for sling. > The login/logout servlets from the org.apache.sling.commons.auth are used. > The AuthenticationHandler will use http basic auth credentials if they are on > the request, otherwise it will use the user/pwd posted from the login form. > The login form html is generated by a set of scripts > 1. login.html.esp - full login page (includes login_body.html.esp for the > form markup) > 2. login_body.html.esp - just the login form, which may be useful for > drawing the login form for an ajax context > 3. loginError.html.esp - full login-error page > 4. loginError_body.html.esp - just the login-error form, for login error in > ajax context > The above scripts are included as bundle-resources @ > /libs/sling/servlet/default > The bundle also has a couple of test scripts to show some examples of usage: > 1. loginTest.html.esp - shows who is logged in and links to login or logout > 2. loginTest2.html.esp - shows how a script can check permissions and show a > login page if the anonymous user doesn't have permission to see the page, > Some examples of usage are: > 1. http://host:port/path/to/node.login.html - show the login page and then > goto http://host:port/path/to/node after authenticated > 2. http://host:port/path/to/node.login.html?s=.edit.html - show the login > page and then goto http://host:port/path/to/node.edit.html after > authenticated > 3. http://host:port/system/sling/logout - invalidate the session and switch > back to anonymous user -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1116) FORM Based Authentication
[ https://issues.apache.org/jira/browse/SLING-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12828272#action_12828272 ] Ian Boston commented on SLING-1116: --- sorry for the noise, looks like the the crypto api needs warming up before using, problems goes away is a dummy hmac is done in construction. > FORM Based Authentication > - > > Key: SLING-1116 > URL: https://issues.apache.org/jira/browse/SLING-1116 > Project: Sling > Issue Type: New Feature > Components: Extensions >Reporter: Eric Norman >Assignee: Felix Meschberger > Attachments: org.apache.sling.cookieauth.zip, > org.apache.sling.sessionauth.zip, SLING_1116_jackrabbit_server_patch.txt, > updated_org.apache.sling.cookieauth.zip > > > This is a new bundle that provides an implementation of forms based > authentication for sling. > The login/logout servlets from the org.apache.sling.commons.auth are used. > The AuthenticationHandler will use http basic auth credentials if they are on > the request, otherwise it will use the user/pwd posted from the login form. > The login form html is generated by a set of scripts > 1. login.html.esp - full login page (includes login_body.html.esp for the > form markup) > 2. login_body.html.esp - just the login form, which may be useful for > drawing the login form for an ajax context > 3. loginError.html.esp - full login-error page > 4. loginError_body.html.esp - just the login-error form, for login error in > ajax context > The above scripts are included as bundle-resources @ > /libs/sling/servlet/default > The bundle also has a couple of test scripts to show some examples of usage: > 1. loginTest.html.esp - shows who is logged in and links to login or logout > 2. loginTest2.html.esp - shows how a script can check permissions and show a > login page if the anonymous user doesn't have permission to see the page, > Some examples of usage are: > 1. http://host:port/path/to/node.login.html - show the login page and then > goto http://host:port/path/to/node after authenticated > 2. http://host:port/path/to/node.login.html?s=.edit.html - show the login > page and then goto http://host:port/path/to/node.edit.html after > authenticated > 3. http://host:port/system/sling/logout - invalidate the session and switch > back to anonymous user -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-1340) TRACE is supported and probably should not be by default
[ https://issues.apache.org/jira/browse/SLING-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston reassigned SLING-1340: - Assignee: Ian Boston > TRACE is supported and probably should not be by default > > > Key: SLING-1340 > URL: https://issues.apache.org/jira/browse/SLING-1340 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: Engine 2.1.0 > > > A per httpd, TRACE should be off by default. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1340) TRACE is supported and probably should not be by default
[
https://issues.apache.org/jira/browse/SLING-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12828373#action_12828373
]
Ian Boston commented on SLING-1340:
---
If the tace method is denied the SlingMainServlet will respond with
response.sendError(405);
response.setHeader("Allow", "GET, HEAD, POST, PUT, DELETE, OPTIONS");
Configured by a boolean property on the SlingMainServlet
sling.trace.allow
default value is false denying TRACE.
> TRACE is supported and probably should not be by default
>
>
> Key: SLING-1340
> URL: https://issues.apache.org/jira/browse/SLING-1340
> Project: Sling
> Issue Type: Bug
> Components: Engine
>Affects Versions: Engine 2.0.6
>Reporter: Ian Boston
>Assignee: Ian Boston
> Fix For: Engine 2.1.0
>
>
> A per httpd, TRACE should be off by default.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1340) TRACE is supported and probably should not be by default
[ https://issues.apache.org/jira/browse/SLING-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston resolved SLING-1340. --- Resolution: Fixed Fixed, 905485 > TRACE is supported and probably should not be by default > > > Key: SLING-1340 > URL: https://issues.apache.org/jira/browse/SLING-1340 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: Engine 2.1.0 > > > A per httpd, TRACE should be off by default. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SLING-1340) TRACE is supported and probably should not be by default
[ https://issues.apache.org/jira/browse/SLING-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12828379#action_12828379 ] Ian Boston edited comment on SLING-1340 at 2/2/10 1:09 AM: --- Fixed, r905486 was (Author: ianeboston): Fixed, 905485 > TRACE is supported and probably should not be by default > > > Key: SLING-1340 > URL: https://issues.apache.org/jira/browse/SLING-1340 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: Engine 2.1.0 > > > A per httpd, TRACE should be off by default. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1344) Possible response split in SlingSafeMethodsServlet
Possible response split in SlingSafeMethodsServlet -- Key: SLING-1344 URL: https://issues.apache.org/jira/browse/SLING-1344 Project: Sling Issue Type: Bug Components: API Affects Versions: API 2.0.8 Reporter: Ian Boston Assignee: Ian Boston Fix For: API 2.0.10 Headers in the doTrace method are echoed to the response, making it potentially possible to split a response. Would suggest encoding the headers both name part and value part correctly IIRC Value part should be URIEncoded ? but name part Eliminate values outside 33 - 126 as per rfc 822 ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1116) FORM Based Authentication
[ https://issues.apache.org/jira/browse/SLING-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12828712#action_12828712 ] Ian Boston commented on SLING-1116: --- I'd be happy to donate bits or all of the bundle from Sakai if appropriate and helpful, or feel free to grab anything you want. > FORM Based Authentication > - > > Key: SLING-1116 > URL: https://issues.apache.org/jira/browse/SLING-1116 > Project: Sling > Issue Type: New Feature > Components: Extensions >Reporter: Eric Norman >Assignee: Felix Meschberger > Attachments: org.apache.sling.cookieauth.zip, > org.apache.sling.sessionauth.zip, SLING_1116_jackrabbit_server_patch.txt, > updated_org.apache.sling.cookieauth.zip > > > This is a new bundle that provides an implementation of forms based > authentication for sling. > The login/logout servlets from the org.apache.sling.commons.auth are used. > The AuthenticationHandler will use http basic auth credentials if they are on > the request, otherwise it will use the user/pwd posted from the login form. > The login form html is generated by a set of scripts > 1. login.html.esp - full login page (includes login_body.html.esp for the > form markup) > 2. login_body.html.esp - just the login form, which may be useful for > drawing the login form for an ajax context > 3. loginError.html.esp - full login-error page > 4. loginError_body.html.esp - just the login-error form, for login error in > ajax context > The above scripts are included as bundle-resources @ > /libs/sling/servlet/default > The bundle also has a couple of test scripts to show some examples of usage: > 1. loginTest.html.esp - shows who is logged in and links to login or logout > 2. loginTest2.html.esp - shows how a script can check permissions and show a > login page if the anonymous user doesn't have permission to see the page, > Some examples of usage are: > 1. http://host:port/path/to/node.login.html - show the login page and then > goto http://host:port/path/to/node after authenticated > 2. http://host:port/path/to/node.login.html?s=.edit.html - show the login > page and then goto http://host:port/path/to/node.edit.html after > authenticated > 3. http://host:port/system/sling/logout - invalidate the session and switch > back to anonymous user -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1351) Launchpad plugin wont merge additional lists correctly.
Launchpad plugin wont merge additional lists correctly. --- Key: SLING-1351 URL: https://issues.apache.org/jira/browse/SLING-1351 Project: Sling Issue Type: Bug Components: Maven Plugins Affects Versions: Launchpad App 6 Reporter: Ian Boston Assignee: Ian Boston Fix For: Launchpad App 6 Merging a list.xml when no default bundle list is used fails. applying patch supplied by Justin to fix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1372) Prepare for jrc bundle releases prior to moving to JR2
Prepare for jrc bundle releases prior to moving to JR2 -- Key: SLING-1372 URL: https://issues.apache.org/jira/browse/SLING-1372 Project: Sling Issue Type: Task Components: JCR Affects Versions: JCR Webdav 2.0.8, JCR Contentloader 2.0.6, JCR Jackrabbit Server 2.0.6, JCR Jackrabbit Access Manager 2.0.4, JCR Base 2.1.0, JCR API 2.0.8 Reporter: Ian Boston Assignee: Ian Boston as per http://markmail.org/thread/q7b6m7hoqius62ah reverting some commits so we can do a release of before moving to JR2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1372) Prepare for jrc bundle releases prior to moving to JR2
[ https://issues.apache.org/jira/browse/SLING-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12833017#action_12833017 ] Ian Boston commented on SLING-1372: --- yes, your right, once jcr.base is reverted it no longer depends on 2.0.7-SNAPSHOT of jcr api, so there is no reason to release that at this time. So a question: When we move to 2 presumably jcr.api will change ? And if so should the changes I reverted to jcr.api be in a pre JR2 world or part of a JR2 world ? > Prepare for jrc bundle releases prior to moving to JR2 > -- > > Key: SLING-1372 > URL: https://issues.apache.org/jira/browse/SLING-1372 > Project: Sling > Issue Type: Task > Components: JCR >Affects Versions: JCR Webdav 2.0.8, JCR Contentloader 2.0.6, JCR > Jackrabbit Server 2.0.6, JCR Jackrabbit Access Manager 2.0.4, JCR Base > 2.1.0, JCR API 2.0.8 >Reporter: Ian Boston >Assignee: Ian Boston > > as per http://markmail.org/thread/q7b6m7hoqius62ah > reverting some commits so we can do a release of before moving to JR2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1372) Prepare for jrc bundle releases prior to moving to JR2
[ https://issues.apache.org/jira/browse/SLING-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston resolved SLING-1372. --- Resolution: Fixed Fix Version/s: JCR Base 2.1.0 JCR Jackrabbit Access Manager 2.0.4 JCR Jackrabbit Server 2.0.6 JCR Contentloader 2.0.6 JCR Webdav 2.0.8 Ready, (need to change the version of jcr base and create a new jcr base version) > Prepare for jrc bundle releases prior to moving to JR2 > -- > > Key: SLING-1372 > URL: https://issues.apache.org/jira/browse/SLING-1372 > Project: Sling > Issue Type: Task > Components: JCR >Affects Versions: JCR Webdav 2.0.8, JCR Contentloader 2.0.6, JCR > Jackrabbit Server 2.0.6, JCR Jackrabbit Access Manager 2.0.4, JCR Base 2.1.0 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: JCR Webdav 2.0.8, JCR Contentloader 2.0.6, JCR > Jackrabbit Server 2.0.6, JCR Jackrabbit Access Manager 2.0.4, JCR Base 2.1.0 > > > as per http://markmail.org/thread/q7b6m7hoqius62ah > reverting some commits so we can do a release of before moving to JR2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1372) Prepare for jrc bundle releases prior to moving to JR2
[ https://issues.apache.org/jira/browse/SLING-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston updated SLING-1372: -- Affects Version/s: (was: JCR API 2.0.8) > Prepare for jrc bundle releases prior to moving to JR2 > -- > > Key: SLING-1372 > URL: https://issues.apache.org/jira/browse/SLING-1372 > Project: Sling > Issue Type: Task > Components: JCR >Affects Versions: JCR Webdav 2.0.8, JCR Contentloader 2.0.6, JCR > Jackrabbit Server 2.0.6, JCR Jackrabbit Access Manager 2.0.4, JCR Base 2.1.0 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: JCR Webdav 2.0.8, JCR Contentloader 2.0.6, JCR > Jackrabbit Server 2.0.6, JCR Jackrabbit Access Manager 2.0.4, JCR Base 2.1.0 > > > as per http://markmail.org/thread/q7b6m7hoqius62ah > reverting some commits so we can do a release of before moving to JR2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1190) Upgrade Jackrabbit Dependency to 1.6
[ https://issues.apache.org/jira/browse/SLING-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston resolved SLING-1190. --- Resolution: Fixed AFAIK, this can be resolved, patch was applied and Sling is on 16 > Upgrade Jackrabbit Dependency to 1.6 > > > Key: SLING-1190 > URL: https://issues.apache.org/jira/browse/SLING-1190 > Project: Sling > Issue Type: Improvement > Components: JCR >Affects Versions: JCR Jackrabbit Server 2.0.4 >Reporter: Mike Moulton >Assignee: Felix Meschberger > Fix For: JCR Jackrabbit Server 2.0.6 > > Attachments: SLING-1190.patch > > > Since 1.6 was released in August I think Sling should upgrade it's > dependencies to Jackrabbit 1.6. Aside from the many bug fixes in 1.6, there > are significant improvements to performance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1132) JCR Server Bundle has wrong bundle version
[ https://issues.apache.org/jira/browse/SLING-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston updated SLING-1132: -- Priority: Blocker (was: Major) > JCR Server Bundle has wrong bundle version > -- > > Key: SLING-1132 > URL: https://issues.apache.org/jira/browse/SLING-1132 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR Jackrabbit Server 2.0.4 >Reporter: Carsten Ziegeler >Priority: Blocker > Fix For: JCR Jackrabbit Server 2.0.6 > > > The 2.0.4-incubator release of the server bundle has the hardcoded > 2.0.3-incubator-SNAPSHOT version as bundle version (and for the exports) This > is due to the fact that we hard-code the manifest instead of letting it get > generated by the bundle plugin. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1132) JCR Server Bundle has wrong bundle version
[ https://issues.apache.org/jira/browse/SLING-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12833033#action_12833033 ] Ian Boston commented on SLING-1132: --- Warning: before doing the 2.0.6 release the manifest MUST be edited. Its currently at 2.0.5-SNAPSHOT > JCR Server Bundle has wrong bundle version > -- > > Key: SLING-1132 > URL: https://issues.apache.org/jira/browse/SLING-1132 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR Jackrabbit Server 2.0.4 >Reporter: Carsten Ziegeler > Fix For: JCR Jackrabbit Server 2.0.6 > > > The 2.0.4-incubator release of the server bundle has the hardcoded > 2.0.3-incubator-SNAPSHOT version as bundle version (and for the exports) This > is due to the fact that we hard-code the manifest instead of letting it get > generated by the bundle plugin. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1363) Add a component which allows bundles to configure the session returned by SlingRepository
[ https://issues.apache.org/jira/browse/SLING-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston updated SLING-1363: -- Fix Version/s: (was: JCR API 2.0.8) (was: JCR Base 2.0.6) JCR Base 2.1.0 Moving to 2.1.0 and reopening (to remind me to revert the patch applied to do the 2.0.6 release) > Add a component which allows bundles to configure the session returned by > SlingRepository > - > > Key: SLING-1363 > URL: https://issues.apache.org/jira/browse/SLING-1363 > Project: Sling > Issue Type: Improvement > Components: JCR >Reporter: Justin Edelson >Assignee: Justin Edelson > Fix For: JCR Base 2.1.0 > > > discussion in http://markmail.org/thread/umuk7beuisp6zoqs -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (SLING-1363) Add a component which allows bundles to configure the session returned by SlingRepository
[ https://issues.apache.org/jira/browse/SLING-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston reopened SLING-1363: --- Reopening so I/we dont forget to undo changes for the 2.0.6 release > Add a component which allows bundles to configure the session returned by > SlingRepository > - > > Key: SLING-1363 > URL: https://issues.apache.org/jira/browse/SLING-1363 > Project: Sling > Issue Type: Improvement > Components: JCR >Reporter: Justin Edelson >Assignee: Justin Edelson > Fix For: JCR Base 2.1.0 > > > discussion in http://markmail.org/thread/umuk7beuisp6zoqs -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1366) NamespaceMapper is never called
[ https://issues.apache.org/jira/browse/SLING-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston resolved SLING-1366. --- Resolution: Fixed Believed to be fixed in the 2.0.6 release, after the ACE tests were fixed by r909432 > NamespaceMapper is never called > --- > > Key: SLING-1366 > URL: https://issues.apache.org/jira/browse/SLING-1366 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR Base 2.0.4 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: JCR Base 2.0.6 > > > It seems that the NamespaceMapper is never called - therefore the support for > the bundle header "Sling-Namespaces" is not working anymore -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1132) JCR Server Bundle has wrong bundle version
[ https://issues.apache.org/jira/browse/SLING-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston updated SLING-1132: -- Fix Version/s: (was: JCR Jackrabbit Server 2.0.6) JCR Jackrabbit Server 2.0.8 Updated version in manifest in r909472, moving this jira to next release so that the version can be moved on there. > JCR Server Bundle has wrong bundle version > -- > > Key: SLING-1132 > URL: https://issues.apache.org/jira/browse/SLING-1132 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR Jackrabbit Server 2.0.4 >Reporter: Carsten Ziegeler >Priority: Blocker > Fix For: JCR Jackrabbit Server 2.0.8 > > > The 2.0.4-incubator release of the server bundle has the hardcoded > 2.0.3-incubator-SNAPSHOT version as bundle version (and for the exports) This > is due to the fact that we hard-code the manifest instead of letting it get > generated by the bundle plugin. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (SLING-1366) NamespaceMapper is never called
[ https://issues.apache.org/jira/browse/SLING-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston reopened SLING-1366: --- curl -u admin:admin http://localhost:/index.html?sudo=anonymous giving 12.02.2010 16:42:51.123 *WARN* [2854...@qtp-24914065-10] org.mortbay.jetty EXCEPTION java.lang.ClassCastException: org.apache.sling.jcr.base.SessionProxyHandler$SessionProxy cannot be cast to javax.jcr.Session at $Proxy4.impersonate(Unknown Source) at org.apache.sling.commons.auth.impl.SlingAuthenticator.handleImpersonation(SlingAuthenticator.java:877) at org.apache.sling.commons.auth.impl.SlingAuthenticator.getSession(SlingAuthenticator.java:545) at org.apache.sling.commons.auth.impl.SlingAuthenticator.handleSecurity(SlingAuthenticator.java:358) at org.apache.sling.engine.impl.SlingMainServlet.handleSecurity(SlingMainServlet.java:859) > NamespaceMapper is never called > --- > > Key: SLING-1366 > URL: https://issues.apache.org/jira/browse/SLING-1366 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR Base 2.0.4 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: JCR Base 2.0.6 > > > It seems that the NamespaceMapper is never called - therefore the support for > the bundle header "Sling-Namespaces" is not working anymore -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1129) Patch to make it easier to extend JcrResourceResolver2 and its factory.
[ https://issues.apache.org/jira/browse/SLING-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston resolved SLING-1129. --- Resolution: Won't Fix This was one of my worse ideas. The extension mechanism was to allow virtualization of URL space relative to JCR space, on the face of it a good idea, but it abuses some fundamentals of JCR, re-abstracts some of the JCR concepts and opens a pandora's box of problems for http clients and implementation. IMVHO this should be closed as wont fix, as there are better ways to do the above using the JcrResourceResolver as it stands. > Patch to make it easier to extend JcrResourceResolver2 and its factory. > --- > > Key: SLING-1129 > URL: https://issues.apache.org/jira/browse/SLING-1129 > Project: Sling > Issue Type: Improvement > Components: JCR >Affects Versions: JCR Resource 2.0.4 >Reporter: Ian Boston > Fix For: JCR Resource 2.0.8 > > Attachments: SLING-1129.diff > > > At the moment, its hard if not impossible to extend the functionallity of the > JcrResourceResolver2 and its Factory without succumbing to the dangerous > practice of duplicating and patching implementation code. > The patch to follow add some small extension points that makes it possible to > extend the Factory as a component, and the JcrResourceResolver2 itself. It > make no changes to functionality or API. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1351) Launchpad plugin wont merge additional lists correctly.
[ https://issues.apache.org/jira/browse/SLING-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12837861#action_12837861 ] Ian Boston commented on SLING-1351: --- The patch appears to merge everything into start level 0. Doing some more. > Launchpad plugin wont merge additional lists correctly. > --- > > Key: SLING-1351 > URL: https://issues.apache.org/jira/browse/SLING-1351 > Project: Sling > Issue Type: Bug > Components: Maven Plugins >Affects Versions: Launchpad App 6 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: Launchpad App 6 > > > Merging a list.xml when no default bundle list is used fails. > applying patch supplied by Justin to fix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1351) Launchpad plugin wont merge additional lists correctly.
[ https://issues.apache.org/jira/browse/SLING-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston resolved SLING-1351. --- Resolution: Fixed Fixed. > Launchpad plugin wont merge additional lists correctly. > --- > > Key: SLING-1351 > URL: https://issues.apache.org/jira/browse/SLING-1351 > Project: Sling > Issue Type: Bug > Components: Maven Plugins >Affects Versions: Launchpad App 6 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: Launchpad App 6 > > > Merging a list.xml when no default bundle list is used fails. > applying patch supplied by Justin to fix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1344) Possible response split in SlingSafeMethodsServlet
[ https://issues.apache.org/jira/browse/SLING-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston resolved SLING-1344. --- Resolution: Not A Problem Since TRACE is disabled by default this is now a non issue. > Possible response split in SlingSafeMethodsServlet > -- > > Key: SLING-1344 > URL: https://issues.apache.org/jira/browse/SLING-1344 > Project: Sling > Issue Type: Bug > Components: API >Affects Versions: API 2.0.8 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: API 2.1.0 > > > Headers in the doTrace method are echoed to the response, making it > potentially possible to split a response. > Would suggest encoding the headers both name part and value part correctly > IIRC Value part should be URIEncoded ? > > but name part Eliminate values outside 33 - 126 as per rfc 822 ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1470) Sometimes redirect.cnd does not load first time.
Sometimes redirect.cnd does not load first time. Key: SLING-1470 URL: https://issues.apache.org/jira/browse/SLING-1470 Project: Sling Issue Type: Bug Affects Versions: JCR Resource 2.0.6, Servlets Get 2.0.8 Reporter: Ian Boston At times redriect.cnd does not load since it depends on resource.cnd as per [1] moving to jcr/resource bundle 1. http://markmail.org/thread/zat4qjtngysahbn3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1472) Form Auth seems unoperational
[ https://issues.apache.org/jira/browse/SLING-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12853792#action_12853792 ] Ian Boston commented on SLING-1472: --- First off the Sakai form login code is different from Sling since is uses a shared HMAC service to generate tokens to track logins, so we fixed that code separately (in Sakai Nakamura). It was broken because it was bound to the old Authentication API. The code in the Sling httpauth extension bundle is (AFAICT) using the current AuthenticationHandler SPI. AFAIK Sling does not use j_security_check but I could be wrong. The reason /system/sling/logout results in a popup is it responds with a 401. Since curl http://localhost:8181/system/sling/form/login returns a 404, I would check that you have a AuthenticationFormServlet under the list of Components in the Sling Console. > Form Auth seems unoperational > - > > Key: SLING-1472 > URL: https://issues.apache.org/jira/browse/SLING-1472 > Project: Sling > Issue Type: Bug > Components: Extensions > Environment: sling trunk -r930334 on fuse 4.2 >Reporter: Jason Rose > > Installing bundle > mvn:org.apache.sling/org.apache.sling.formauth/0.9-SNAPSHOT doesn't seem to > actually provide any functionality. > curl http://localhost:8181/system/sling/form/login returns a 404. > The authentication handler itself doesn't seem to provide any login or logout > support; if I post to /j_security_check with the correct credentials, the > basic auth handler handles it. I don't know if the form auth code is even > running at all. Calling /system/sling/logout pops up the basic challenge > modal in my browser. > It looks like there was a Sakai bug raised about this a while ago, and they > fixed it. I don't know if the code was backported, or what. > http://jira.sakaiproject.org/browse/KERN-716 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1175) Potential Invinite Recursion in JCRResourceResolver2
[ https://issues.apache.org/jira/browse/SLING-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston resolved SLING-1175. --- Resolution: Fixed AFAIK, this issue was removed when we refactored the resolver to use map of maps. > Potential Invinite Recursion in JCRResourceResolver2 > > > Key: SLING-1175 > URL: https://issues.apache.org/jira/browse/SLING-1175 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR Resource 2.0.6 >Reporter: Ian Boston > Fix For: JCR Resource 2.0.8 > > > In JCRResourceResolver.getProperty if a path resolves to a Synthetic > Resource, then unless the Resolution can distinguish between a property and > node by name it will recurse forever. > I am not certain what the solution should be, either the provider of the > synthetic resource should be more intelligent, or JcrResourceResolver2 should > guard against recursion. > around line 752 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1470) Sometimes redirect.cnd does not load first time.
[ https://issues.apache.org/jira/browse/SLING-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston resolved SLING-1470. --- Resolution: Fixed Fix Version/s: JCR Resource 2.0.8 Servlets Get 2.0.10 Moved redirect.cnd and adjusted the build > Sometimes redirect.cnd does not load first time. > > > Key: SLING-1470 > URL: https://issues.apache.org/jira/browse/SLING-1470 > Project: Sling > Issue Type: Bug > Components: JCR, Servlets >Affects Versions: Servlets Get 2.0.8, JCR Resource 2.0.6 >Reporter: Ian Boston > Fix For: Servlets Get 2.0.10, JCR Resource 2.0.8 > > > At times redriect.cnd does not load since it depends on resource.cnd > as per [1] moving to jcr/resource bundle > 1. http://markmail.org/thread/zat4qjtngysahbn3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1496) A GET request to a directory results in a response with no content type, confusing some browsers.
A GET request to a directory results in a response with no content type, confusing some browsers. - Key: SLING-1496 URL: https://issues.apache.org/jira/browse/SLING-1496 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Get 2.0.8 Reporter: Ian Boston Assignee: Ian Boston Fix For: Servlets Get 2.0.10 As per http://markmail.org/thread/2kxoab4eg5sqhdz6 a request to a directory eg /dev/ which contains an index.html file results in a response with no content type. Identified that included resources that are streamed dont set any response headers indicating that the headers must be set before the body is included. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1496) A GET request to a directory results in a response with no content type, confusing some browsers.
[ https://issues.apache.org/jira/browse/SLING-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston resolved SLING-1496. --- Resolution: Fixed Fixed. Where a directory contains an index resource (eg index.html) the resource is inspected for properties and response headers are set prior to being included. Subsequent processing may still change the headers if required, but if it omits to do so, default headers (mainly content-type) will be there. > A GET request to a directory results in a response with no content type, > confusing some browsers. > - > > Key: SLING-1496 > URL: https://issues.apache.org/jira/browse/SLING-1496 > Project: Sling > Issue Type: Bug > Components: Servlets >Affects Versions: Servlets Get 2.0.8 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: Servlets Get 2.0.10 > > > As per http://markmail.org/thread/2kxoab4eg5sqhdz6 > a request to a directory eg /dev/ which contains an index.html file results > in a response with no content type. > Identified that included resources that are streamed dont set any response > headers indicating that the headers must be set before the body is included. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1308) Node.infinity.json contains risk for DOS.
[ https://issues.apache.org/jira/browse/SLING-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12859663#action_12859663 ] Ian Boston commented on SLING-1308: --- At the moment, I cant see where to update the documentation, as I cant find any documentation on "infinity" > Node.infinity.json contains risk for DOS. > - > > Key: SLING-1308 > URL: https://issues.apache.org/jira/browse/SLING-1308 > Project: Sling > Issue Type: Bug > Components: Servlets >Affects Versions: Servlets Get 2.0.8 >Reporter: Simon Gaeremynck >Assignee: Ian Boston >Priority: Critical > Attachments: jsonRenderer.diff, jsonRenderer.diff > > > As it is now any user can do a node.infinity.json . > If this happens on the root node in a repository with many items, it will > cause the server to slow down (eventually crash?) > I've created a patch confirming the discussion @ > http://markmail.org/search/?q=node.infinity#query:node.infinity+page:1+mid:ugqjyqdz2trfpdkr+state:results -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1516) FSResource Provider throws exception on first activate.
FSResource Provider throws exception on first activate. --- Key: SLING-1516 URL: https://issues.apache.org/jira/browse/SLING-1516 Project: Sling Issue Type: Bug Affects Versions: File System Resource Provider 0.9.2 Reporter: Ian Boston Assignee: Ian Boston Fix For: File System Resource Provider 1.0.2 04.05.2010 11:07:03.367 *ERROR* [SCR Component Actor] org.apache.sling.fsresource [org.apache.sling.fsprovider.internal.FsResourceProvider] The activate method has thrown an exception (java.lang.IllegalArgumentException: provider.roots property must be set) java.lang.IllegalArgumentException: provider.roots property must be set at org.apache.sling.fsprovider.internal.FsResourceProvider.activate(FsResourceProvider.java:206) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:213) at org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:38) Seeing these when FSResource is present and not configured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1516) FSResource Provider throws exception on first activate.
[ https://issues.apache.org/jira/browse/SLING-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12863637#action_12863637 ] Ian Boston commented on SLING-1516: --- FSResource is configured as a ConfigurationFactory however it make not distinction between an activate for an alias PID and the real PID. It should look at the properties to determine why its being activated. see OSGi 4.2 Compendium v 1.1 section 115.3.1 I think a simple check for the existence of the service.factoryPid property should identify when the activation is as a result of a configuration. > FSResource Provider throws exception on first activate. > --- > > Key: SLING-1516 > URL: https://issues.apache.org/jira/browse/SLING-1516 > Project: Sling > Issue Type: Bug >Affects Versions: File System Resource Provider 0.9.2 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: File System Resource Provider 1.0.2 > > > 04.05.2010 11:07:03.367 *ERROR* [SCR Component Actor] > org.apache.sling.fsresource > [org.apache.sling.fsprovider.internal.FsResourceProvider] The activate method > has thrown an exception (java.lang.IllegalArgumentException: provider.roots > property must be set) java.lang.IllegalArgumentException: provider.roots > property must be set > at > org.apache.sling.fsprovider.internal.FsResourceProvider.activate(FsResourceProvider.java:206) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:213) > at > org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:38) > Seeing these when FSResource is present and not configured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1516) FSResource Provider throws exception on first activate.
[ https://issues.apache.org/jira/browse/SLING-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston resolved SLING-1516. --- Resolution: Fixed Fixed. > FSResource Provider throws exception on first activate. > --- > > Key: SLING-1516 > URL: https://issues.apache.org/jira/browse/SLING-1516 > Project: Sling > Issue Type: Bug >Affects Versions: File System Resource Provider 0.9.2 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: File System Resource Provider 1.0.2 > > > 04.05.2010 11:07:03.367 *ERROR* [SCR Component Actor] > org.apache.sling.fsresource > [org.apache.sling.fsprovider.internal.FsResourceProvider] The activate method > has thrown an exception (java.lang.IllegalArgumentException: provider.roots > property must be set) java.lang.IllegalArgumentException: provider.roots > property must be set > at > org.apache.sling.fsprovider.internal.FsResourceProvider.activate(FsResourceProvider.java:206) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:213) > at > org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:38) > Seeing these when FSResource is present and not configured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1516) FSResource Provider throws exception on first activate.
[ https://issues.apache.org/jira/browse/SLING-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston resolved SLING-1516. --- Resolution: Fixed Yes, thats a much better way of doing it. I couldnt make much sense of the spec in this area, so thank you. Reverted my attempt and used your suggestion. Fixes the problem. > FSResource Provider throws exception on first activate. > --- > > Key: SLING-1516 > URL: https://issues.apache.org/jira/browse/SLING-1516 > Project: Sling > Issue Type: Bug >Affects Versions: File System Resource Provider 0.9.2 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: File System Resource Provider 1.0.2 > > > 04.05.2010 11:07:03.367 *ERROR* [SCR Component Actor] > org.apache.sling.fsresource > [org.apache.sling.fsprovider.internal.FsResourceProvider] The activate method > has thrown an exception (java.lang.IllegalArgumentException: provider.roots > property must be set) java.lang.IllegalArgumentException: provider.roots > property must be set > at > org.apache.sling.fsprovider.internal.FsResourceProvider.activate(FsResourceProvider.java:206) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:213) > at > org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:38) > Seeing these when FSResource is present and not configured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1522) AccessControlUtil looks up an Authorizable where it does not need to.
AccessControlUtil looks up an Authorizable where it does not need to. - Key: SLING-1522 URL: https://issues.apache.org/jira/browse/SLING-1522 Project: Sling Issue Type: Bug Components: JCR Affects Versions: JCR Base 2.0.6 Reporter: Ian Boston Fix For: JCR Base 2.1.0 AccessControlUtil looksup an Authoriable in replaceAccessControlEntry, only to get the Id of the authorizable for a debug statement that asserts the ID is the principalId. Firstly authorizableId might not be principalId, and secondly its perfectly possible to have principals that dont have authorizables. Its a small patch, with no impact, I will fix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-1522) AccessControlUtil looks up an Authorizable where it does not need to.
[ https://issues.apache.org/jira/browse/SLING-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston reassigned SLING-1522: - Assignee: Ian Boston > AccessControlUtil looks up an Authorizable where it does not need to. > - > > Key: SLING-1522 > URL: https://issues.apache.org/jira/browse/SLING-1522 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR Base 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: JCR Base 2.1.0 > > > AccessControlUtil looksup an Authoriable in replaceAccessControlEntry, only > to get the Id of the authorizable for a debug statement that asserts the ID > is the principalId. Firstly authorizableId might not be principalId, and > secondly its perfectly possible to have principals that dont have > authorizables. Its a small patch, with no impact, I will fix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1522) AccessControlUtil looks up an Authorizable where it does not need to.
[ https://issues.apache.org/jira/browse/SLING-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston resolved SLING-1522. --- Resolution: Fixed Fixed > AccessControlUtil looks up an Authorizable where it does not need to. > - > > Key: SLING-1522 > URL: https://issues.apache.org/jira/browse/SLING-1522 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR Base 2.0.6 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: JCR Base 2.1.0 > > > AccessControlUtil looksup an Authoriable in replaceAccessControlEntry, only > to get the Id of the authorizable for a debug statement that asserts the ID > is the principalId. Firstly authorizableId might not be principalId, and > secondly its perfectly possible to have principals that dont have > authorizables. Its a small patch, with no impact, I will fix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1528) Format of GetAclServlet has changed
Format of GetAclServlet has changed
---
Key: SLING-1528
URL: https://issues.apache.org/jira/browse/SLING-1528
Project: Sling
Issue Type: Bug
Components: JCR
Affects Versions: JCR Jackrabbit Access Manager 2.0.6
Reporter: Ian Boston
Fix For: JCR Jackrabbit Access Manager 2.0.6
as per http://markmail.org/thread/7niaxhzxhxv4a2lo
"
Hi,
I am not certain if this was intentional but the format of GetAclServlet was
changed by [1].
Previously the format was a map keyed by principalid, now its an array
containing objects.
I can understand that an array maintains the order of the ACE's in the ACL which
is required by parts of SLING-1458, however its not backwards compatible and
breaks all existing clients that were expecting a map. Since that might be quite
a lot of code, embedded in Client side Javascript apps and server side http
clients, wouldn't it be better to provide keep the format and add a sequence
number to the map objects? , eg
Old format:
{"user1-1274468817" : {"granted":["jcr:read"]}}
New format
[{"principal":"user1-1274468817","granted":["jcr:read"]}]
Suggested new format
{"user1-1274468817" : {"granted":["jcr:read"], "sequence": 0}}
I know the suggested new format is not as natural, however it won't require all
clients to recode.
If we really do want to migrate to an array, then a new selector might be the
way.
eg /node.aclarray.json
WDYT ?
Ian
1 http://svn.apache.org/viewvc?view=revision&revision=927532
"
After leaving this for a few days, there appears to be no objection to changing
the format back to the original with an additional sequence property.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-1528) Format of GetAclServlet has changed
[
https://issues.apache.org/jira/browse/SLING-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Boston reassigned SLING-1528:
-
Assignee: Ian Boston
> Format of GetAclServlet has changed
> ---
>
> Key: SLING-1528
> URL: https://issues.apache.org/jira/browse/SLING-1528
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Affects Versions: JCR Jackrabbit Access Manager 2.0.6
>Reporter: Ian Boston
>Assignee: Ian Boston
> Fix For: JCR Jackrabbit Access Manager 2.0.6
>
>
> as per http://markmail.org/thread/7niaxhzxhxv4a2lo
> "
> Hi,
> I am not certain if this was intentional but the format of GetAclServlet was
> changed by [1].
> Previously the format was a map keyed by principalid, now its an array
> containing objects.
> I can understand that an array maintains the order of the ACE's in the ACL
> which
> is required by parts of SLING-1458, however its not backwards compatible and
> breaks all existing clients that were expecting a map. Since that might be
> quite
> a lot of code, embedded in Client side Javascript apps and server side http
> clients, wouldn't it be better to provide keep the format and add a sequence
> number to the map objects? , eg
> Old format:
> {"user1-1274468817" : {"granted":["jcr:read"]}}
> New format
> [{"principal":"user1-1274468817","granted":["jcr:read"]}]
> Suggested new format
> {"user1-1274468817" : {"granted":["jcr:read"], "sequence": 0}}
> I know the suggested new format is not as natural, however it won't require
> all
> clients to recode.
> If we really do want to migrate to an array, then a new selector might be the
> way.
> eg /node.aclarray.json
> WDYT ?
> Ian
> 1 http://svn.apache.org/viewvc?view=revision&revision=927532
> "
> After leaving this for a few days, there appears to be no objection to
> changing the format back to the original with an additional sequence property.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1528) Format of GetAclServlet has changed
[
https://issues.apache.org/jira/browse/SLING-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Boston resolved SLING-1528.
---
Resolution: Fixed
Fixed,
as per discussion, the format is back to a json map, with a new property
"order" added to each object to reflect its order in the ACL. The Integration
tests have been adjusted to work with the old format.
> Format of GetAclServlet has changed
> ---
>
> Key: SLING-1528
> URL: https://issues.apache.org/jira/browse/SLING-1528
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Affects Versions: JCR Jackrabbit Access Manager 2.0.6
>Reporter: Ian Boston
>Assignee: Ian Boston
> Fix For: JCR Jackrabbit Access Manager 2.0.6
>
>
> as per http://markmail.org/thread/7niaxhzxhxv4a2lo
> "
> Hi,
> I am not certain if this was intentional but the format of GetAclServlet was
> changed by [1].
> Previously the format was a map keyed by principalid, now its an array
> containing objects.
> I can understand that an array maintains the order of the ACE's in the ACL
> which
> is required by parts of SLING-1458, however its not backwards compatible and
> breaks all existing clients that were expecting a map. Since that might be
> quite
> a lot of code, embedded in Client side Javascript apps and server side http
> clients, wouldn't it be better to provide keep the format and add a sequence
> number to the map objects? , eg
> Old format:
> {"user1-1274468817" : {"granted":["jcr:read"]}}
> New format
> [{"principal":"user1-1274468817","granted":["jcr:read"]}]
> Suggested new format
> {"user1-1274468817" : {"granted":["jcr:read"], "sequence": 0}}
> I know the suggested new format is not as natural, however it won't require
> all
> clients to recode.
> If we really do want to migrate to an array, then a new selector might be the
> way.
> eg /node.aclarray.json
> WDYT ?
> Ian
> 1 http://svn.apache.org/viewvc?view=revision&revision=927532
> "
> After leaving this for a few days, there appears to be no objection to
> changing the format back to the original with an additional sequence property.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-1495) Make the Sling integration test cases available as a dependency
[ https://issues.apache.org/jira/browse/SLING-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston reassigned SLING-1495: - Assignee: Ian Boston > Make the Sling integration test cases available as a dependency > --- > > Key: SLING-1495 > URL: https://issues.apache.org/jira/browse/SLING-1495 > Project: Sling > Issue Type: Improvement > Components: Testing >Reporter: Jukka Zitting >Assignee: Ian Boston >Priority: Minor > Attachments: > 0001-SLING-1495-Make-the-Sling-integration-test-cases-av.patch > > > Currently the integration tests in launchpad/testing are designed so that > you'll need to manually run that Maven build with specific options if you > want to test an external Sling instance. > It would be great if a downstream project could instead import those test > cases as a test dependency to their own integration test suite. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
