[jira] [Updated] (SLING-3477) BackgroundHttpServletRequest incompatible with Enging 2.3.0
[ https://issues.apache.org/jira/browse/SLING-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-3477: Fix Version/s: Background Servlet 1.0.0 BackgroundHttpServletRequest incompatible with Enging 2.3.0 --- Key: SLING-3477 URL: https://issues.apache.org/jira/browse/SLING-3477 Project: Sling Issue Type: Bug Components: Extensions Reporter: Christan Keller Assignee: Carsten Ziegeler Priority: Minor Fix For: Background Servlet 1.0.0 Engine 2.3.0 changed the ParameterSupport. It uses the ServletRequest#getInputStream to access Parameters. The BackgroundExecution has an on implemenation of HttpServletRequest that throws a RuntimeException for this method. Thus even with engine 2.3.2 (Sling-3439) the creation of a BackgroundExecutionJob fails. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (SLING-3480) Adding test for replication config delete
[ https://issues.apache.org/jira/browse/SLING-3480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili reassigned SLING-3480: -- Assignee: Tommaso Teofili Adding test for replication config delete - Key: SLING-3480 URL: https://issues.apache.org/jira/browse/SLING-3480 Project: Sling Issue Type: Test Components: Extensions Reporter: Marius Petria Assignee: Tommaso Teofili Priority: Minor Attachments: SLING-3480.patch Adding test for replication config delete and also fixing the test for config create, -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3480) Adding test for replication config delete
[
https://issues.apache.org/jira/browse/SLING-3480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949028#comment-13949028
]
Tommaso Teofili commented on SLING-3480:
the patch looks generally good, however I think there's one thing to fix in
ReplicationITBase#assertJsonResponseContains as {code}
for (int i = 0; i parameters.length; i += 2) {
content.contains(\ + parameters[i] + \:\ + parameters[i + 1]
+ \);
}
{code}
doesn't actually checks if the parameters are contained in the JSON String,
also after adding assertTrue(content.contains ... the test fails so it'd be
good to have that line fixed.
Adding test for replication config delete
-
Key: SLING-3480
URL: https://issues.apache.org/jira/browse/SLING-3480
Project: Sling
Issue Type: Test
Components: Extensions
Reporter: Marius Petria
Assignee: Tommaso Teofili
Priority: Minor
Attachments: SLING-3480.patch
Adding test for replication config delete and also fixing the test for config
create,
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (SLING-3482) Synthetic resources should lead to a 404
Carsten Ziegeler created SLING-3482:
---
Summary: Synthetic resources should lead to a 404
Key: SLING-3482
URL: https://issues.apache.org/jira/browse/SLING-3482
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Resolver 1.0.6
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
Fix For: Resource Resolver 1.1.0
If e.g. /libs is requested by a user who does not have access to /libs, a
synthetic resource for libs is returned which is then rendered.
This is due to the special handling for servlet resources which are mounted at
/libs/
I think the code in ResourceProviderEntry#getInternalResource is too generic:
if (entries.size() 0 entries.size() == elements.length) {
if (entries.get(entries.size() -
1).getResourceProviders().length == 0) {
logger.debug(Resolved Synthetic {}, fullPath);
return new SyntheticResource(resourceResolver, fullPath,
ResourceProvider.RESOURCE_TYPE_SYNTHETIC);
}
}
However, fixing this might break other parts like the servlet resolver relying
on it
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Re: Build failed in Jenkins: sling-contrib-1.6 » Apache Sling MongoDB Resource Provider #1115
Should be fixed with https://svn.apache.org/viewvc?view=revisionrevision=r1582219 . Robert On Thu, Mar 27, 2014 at 1:38 AM, Apache Jenkins Server jenk...@builds.apache.org wrote: See https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.mongodb/1115/ -- [INFO] [INFO] [INFO] Building Apache Sling MongoDB Resource Provider 0.0.1-SNAPSHOT [INFO] Downloading: http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.api/2.6.1-SNAPSHOT/maven-metadata.xml Downloading: http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.api/2.6.1-SNAPSHOT/org.apache.sling.api-2.6.1-SNAPSHOT.pom [WARNING] The POM for org.apache.sling:org.apache.sling.api:jar:2.6.1-SNAPSHOT is missing, no dependency information available Downloading: http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.api/2.6.1-SNAPSHOT/org.apache.sling.api-2.6.1-SNAPSHOT.jar [JENKINS] Archiving disabled -- http://robert.muntea.nu/
[jira] [Commented] (SLING-3477) BackgroundHttpServletRequest incompatible with Enging 2.3.0
[ https://issues.apache.org/jira/browse/SLING-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949057#comment-13949057 ] Christan Keller commented on SLING-3477: Thanks for this quick fix. I will try it BackgroundHttpServletRequest incompatible with Enging 2.3.0 --- Key: SLING-3477 URL: https://issues.apache.org/jira/browse/SLING-3477 Project: Sling Issue Type: Bug Components: Extensions Reporter: Christan Keller Assignee: Carsten Ziegeler Priority: Minor Fix For: Background Servlet 1.0.0 Engine 2.3.0 changed the ParameterSupport. It uses the ServletRequest#getInputStream to access Parameters. The BackgroundExecution has an on implemenation of HttpServletRequest that throws a RuntimeException for this method. Thus even with engine 2.3.2 (Sling-3439) the creation of a BackgroundExecutionJob fails. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3446) [discovery] stale connector - improve osgi dependencies of ConnectorRegistryImpl to avoid IllegalArgumentException on bundle de/activation
[ https://issues.apache.org/jira/browse/SLING-3446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949073#comment-13949073 ] Stefan Egli commented on SLING-3446: This can be reproduced by stoppingstarting the org.apache.sling.discovery.impl.cluster.ClusterViewServiceImpl component (in the felix console) - so whenever ClusterViewServiceImpl is deactivated/activated (probably?) this situation is triggered. [discovery] stale connector - improve osgi dependencies of ConnectorRegistryImpl to avoid IllegalArgumentException on bundle de/activation -- Key: SLING-3446 URL: https://issues.apache.org/jira/browse/SLING-3446 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Discovery Impl 1.0.4 Reporter: Stefan Egli Assignee: Stefan Egli The following warning shows up every 30 sec when deploying a bundle which results in loads of bundle restart: 10.03.2014 18:27:31.107 *WARN* [pool-8-thread-3] org.apache.sling.discovery.impl.topology.connector.TopologyConnectorClient ping: got RuntimeException: java.lang.IllegalArgumentException: ownerId must not be null or empty java.lang.IllegalArgumentException: ownerId must not be null or empty at org.apache.sling.discovery.impl.topology.announcement.Announcement.init(Announcement.java:88) at org.apache.sling.discovery.impl.topology.announcement.Announcement.init(Announcement.java:83) at org.apache.sling.discovery.impl.topology.connector.TopologyConnectorClient.ping(TopologyConnectorClient.java:169) at org.apache.sling.discovery.impl.topology.connector.ConnectorRegistryImpl.pingOutgoingConnectors(ConnectorRegistryImpl.java:138) at org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.issueRemoteHeartbeats(HeartbeatHandler.java:269) at org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.issueHeartbeat(HeartbeatHandler.java:256) at org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.run(HeartbeatHandler.java:209) at org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:105) at org.quartz.core.JobRunShell.run(JobRunShell.java:207) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) at java.lang.Thread.run(Thread.java:662) Even though TopologyConnectorClient is managed by ConnectorRegistryImpl (which is a service), it seems there are cases where ClusterViewServiceImpl can get deactivated but ConnectorRegistryImpl not. Note that restarting discovery.impl fixes the warning from above stale connector. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3477) BackgroundHttpServletRequest incompatible with Enging 2.3.0
[
https://issues.apache.org/jira/browse/SLING-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949086#comment-13949086
]
Christan Keller commented on SLING-3477:
Confirmed working.
Sorry for missing Stacktrace.But was so into int I thought it was obvious...for
sure it is not.
{code}
26.03.2014 10:20:34.564 *INFO* [pool-25-thread-1]
org.apache.sling.bgservlets.impl.ExecutionEngineImpl Starting job
BackgroundRequestExecutionJob, state=RUNNING,
path=/var/bg/jobs/2014/03/27/10/20/1
26.03.2014 10:20:34.566 *ERROR* [pool-25-thread-1]
org.apache.sling.engine.impl.SlingRequestProcessorImpl service: Uncaught
Throwable
org.apache.sling.bgservlets.BackgroundHttpServletRequest$UnsupportedBackgroundOperationException:
This operation is not supported for background requests
at
org.apache.sling.bgservlets.BackgroundHttpServletRequest.getInputStream(BackgroundHttpServletRequest.java:257)
at
org.apache.sling.engine.impl.parameters.ParameterSupport.getRequestParameterMapInternal(ParameterSupport.java:264)
at
org.apache.sling.engine.impl.parameters.ParameterSupport.getParameter(ParameterSupport.java:173)
at
org.apache.sling.engine.impl.SlingHttpServletRequestImpl.getParameter(SlingHttpServletRequestImpl.java:142)
at
org.apache.sling.bgservlets.impl.BackgroundServletStarterFilter.doFilter(BackgroundServletStarterFilter.java:105)
at
org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:60)
at
com.adobe.granite.resourceresolverhelper.impl.ResourceResolverHelperImpl.doFilter(ResourceResolverHelperImpl.java:81)
at
org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:60)
at
org.apache.sling.engine.impl.SlingRequestProcessorImpl.doProcessRequest(SlingRequestProcessorImpl.java:153)
at
org.apache.sling.engine.impl.SlingRequestProcessorImpl.processRequest(SlingRequestProcessorImpl.java:249)
at
org.apache.sling.bgservlets.impl.BackgroundRequestExecutionJob.run(BackgroundRequestExecutionJob.java:99)
at
org.apache.sling.bgservlets.impl.ExecutionEngineImpl$RunnableWrapper.run(ExecutionEngineImpl.java:87)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
{code}
BackgroundHttpServletRequest incompatible with Enging 2.3.0
---
Key: SLING-3477
URL: https://issues.apache.org/jira/browse/SLING-3477
Project: Sling
Issue Type: Bug
Components: Extensions
Reporter: Christan Keller
Assignee: Carsten Ziegeler
Priority: Minor
Fix For: Background Servlet 1.0.0
Engine 2.3.0 changed the ParameterSupport.
It uses the ServletRequest#getInputStream to access Parameters.
The BackgroundExecution has an on implemenation of HttpServletRequest that
throws a RuntimeException for this method.
Thus even with engine 2.3.2 (Sling-3439) the creation of a
BackgroundExecutionJob fails.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (SLING-3446) [discovery] stale connector - improve osgi dependencies of ConnectorRegistryImpl to avoid IllegalArgumentException on bundle de/activation
[ https://issues.apache.org/jira/browse/SLING-3446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli resolved SLING-3446. Resolution: Fixed Fix Version/s: Discovery Impl 1.0.6 Fixed. DiscoveryServiceImpl re-registers the connector urls on activate - so ConnectorRegistryImpl should accept this, instead of throwing an IllegalStateException that registering twice is not allowed [discovery] stale connector - improve osgi dependencies of ConnectorRegistryImpl to avoid IllegalArgumentException on bundle de/activation -- Key: SLING-3446 URL: https://issues.apache.org/jira/browse/SLING-3446 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Discovery Impl 1.0.4 Reporter: Stefan Egli Assignee: Stefan Egli Fix For: Discovery Impl 1.0.6 The following warning shows up every 30 sec when deploying a bundle which results in loads of bundle restart: 10.03.2014 18:27:31.107 *WARN* [pool-8-thread-3] org.apache.sling.discovery.impl.topology.connector.TopologyConnectorClient ping: got RuntimeException: java.lang.IllegalArgumentException: ownerId must not be null or empty java.lang.IllegalArgumentException: ownerId must not be null or empty at org.apache.sling.discovery.impl.topology.announcement.Announcement.init(Announcement.java:88) at org.apache.sling.discovery.impl.topology.announcement.Announcement.init(Announcement.java:83) at org.apache.sling.discovery.impl.topology.connector.TopologyConnectorClient.ping(TopologyConnectorClient.java:169) at org.apache.sling.discovery.impl.topology.connector.ConnectorRegistryImpl.pingOutgoingConnectors(ConnectorRegistryImpl.java:138) at org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.issueRemoteHeartbeats(HeartbeatHandler.java:269) at org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.issueHeartbeat(HeartbeatHandler.java:256) at org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.run(HeartbeatHandler.java:209) at org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:105) at org.quartz.core.JobRunShell.run(JobRunShell.java:207) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) at java.lang.Thread.run(Thread.java:662) Even though TopologyConnectorClient is managed by ConnectorRegistryImpl (which is a service), it seems there are cases where ClusterViewServiceImpl can get deactivated but ConnectorRegistryImpl not. Note that restarting discovery.impl fixes the warning from above stale connector. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3464) The DynamicClassLoaderManager doesn't reload classes when a bundle transitions from STARTED to RESOLVED
[ https://issues.apache.org/jira/browse/SLING-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-3464: Description: The bundle activator from org.apache.sling.commons.classloader also acts as a SynchronousBundleListener, taking care to clean the DynamicClassLoaderManager (DCLM) when a bundle changes its state. However, the DCLM doesn't get cleaned when a bundle transitions from ACTIVE to RESOLVED, which is inconsistent: for example no services will be resolved from that bundle, however classes already loaded through DCLM will get solved. was: The bundle activator from org.apache.sling.commons.classloader also acts as a SynchronousBundleListener, taking care to clean the DynamicClassLoaderManager (DCLM) when a bundle changes its state. However, the DCLM doesn't get cleaned when a bundle transitions from STARTED to RESOLVED, which is inconsistent: for example no services will be resolved from that bundle, however classes already loaded through DCLM will get solved. The DynamicClassLoaderManager doesn't reload classes when a bundle transitions from STARTED to RESOLVED --- Key: SLING-3464 URL: https://issues.apache.org/jira/browse/SLING-3464 Project: Sling Issue Type: Bug Components: Commons Affects Versions: Commons ClassLoader 1.3.0 Reporter: Radu Cotescu Fix For: Commons ClassLoader 1.3.2 The bundle activator from org.apache.sling.commons.classloader also acts as a SynchronousBundleListener, taking care to clean the DynamicClassLoaderManager (DCLM) when a bundle changes its state. However, the DCLM doesn't get cleaned when a bundle transitions from ACTIVE to RESOLVED, which is inconsistent: for example no services will be resolved from that bundle, however classes already loaded through DCLM will get solved. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3464) The DynamicClassLoaderManager doesn't reload classes when a bundle transitions from STARTED to RESOLVED
[ https://issues.apache.org/jira/browse/SLING-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949105#comment-13949105 ] Carsten Ziegeler commented on SLING-3464: - I guess, you mean from ACTIVE to RESOLVED. The package admin class loader only loads classes when the bundle is ACTIVE - this is to avoid the problem, that the interface class is already available (jsp for example compiles fine) but the service is not. Therefore, when a bundle goes back into the RESOLVED state, we should handle this The DynamicClassLoaderManager doesn't reload classes when a bundle transitions from STARTED to RESOLVED --- Key: SLING-3464 URL: https://issues.apache.org/jira/browse/SLING-3464 Project: Sling Issue Type: Bug Components: Commons Affects Versions: Commons ClassLoader 1.3.0 Reporter: Radu Cotescu Fix For: Commons ClassLoader 1.3.2 The bundle activator from org.apache.sling.commons.classloader also acts as a SynchronousBundleListener, taking care to clean the DynamicClassLoaderManager (DCLM) when a bundle changes its state. However, the DCLM doesn't get cleaned when a bundle transitions from ACTIVE to RESOLVED, which is inconsistent: for example no services will be resolved from that bundle, however classes already loaded through DCLM will get solved. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (SLING-3483) Remove sling:features support from the resource resolver, for now
Bertrand Delacretaz created SLING-3483:
--
Summary: Remove sling:features support from the resource resolver,
for now
Key: SLING-3483
URL: https://issues.apache.org/jira/browse/SLING-3483
Project: Sling
Issue Type: Improvement
Components: ResourceResolver
Affects Versions: Resource Resolver 1.0.6
Reporter: Bertrand Delacretaz
Assignee: Bertrand Delacretaz
Priority: Minor
As discussed on list ( http://markmail.org/message/nuaiox2gkmutttdo ) I believe
the current magic support of the sling:features resource property in the
resource resolver core opens a can of worms in some cases. Carsten agrees and
we'd like to remove that support from the core resource resolver bundle for now.
[~justinedelson] was not fully convinced of removing it in that discussion, but
AFAICS he agrees about moving that functionality to a separate bundle that we
can then clearly label as experimental.
In the current code, the decision to hide a resource based on feature flags is
done in a single place, in the ProviderHandler class:
{code}
Resource getReadableResource ( final ResourceResolverContext ctx, ...){
Resource returnValue = null;
...set returnValue unless resourceAccessSecurity objects...
...and now ctx can decide to hide the resource based on sling:features
return ctx.applyFeatures(returnValue);
}
{code}
So using a service implemented in a different bundle is not a problem, it would
just be used instead of (or inside) the ResourceResolverContext. That service
only needs to know about the Resource and the features services, it doesn't
need any internal knowledge of the resource resolver state.
For now I'll go ahead and remove the sling:features support from the
resourceresolver bundle, and we can later experiment and re-add it with a more
modular design.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (SLING-3483) Remove sling:features support from the resource resolver, for now
[
https://issues.apache.org/jira/browse/SLING-3483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz updated SLING-3483:
---
Description:
As discussed on list ( http://markmail.org/message/nuaiox2gkmutttdo ) I believe
the current magic support of the sling:features resource property in the
resource resolver core opens a can of worms in some cases. Carsten agrees and
we'd like to remove that support from the core resource resolver bundle for now.
[~justinedelson] was not fully convinced of removing it in that discussion, but
AFAICS he agrees about moving that functionality to a separate bundle that we
can then clearly label as experimental.
In the current code, the decision to hide a resource based on feature flags is
done in a single place, in the ProviderHandler class:
Resource getReadableResource ( final ResourceResolverContext ctx, ...){
Resource returnValue = null;
...set returnValue unless resourceAccessSecurity objects...
...and now ctx can decide to hide the resource based on sling:features
return ctx.applyFeatures(returnValue);
}
So using a service implemented in a different bundle is not a problem, it would
just be used instead of (or inside) the ResourceResolverContext. That service
only needs to know about the Resource and the features services, it doesn't
need any internal knowledge of the resource resolver state.
For now I'll go ahead and remove the sling:features support from the
resourceresolver bundle, and we can later experiment and re-add it with a more
modular design.
was:
As discussed on list ( http://markmail.org/message/nuaiox2gkmutttdo ) I believe
the current magic support of the sling:features resource property in the
resource resolver core opens a can of worms in some cases. Carsten agrees and
we'd like to remove that support from the core resource resolver bundle for now.
[~justinedelson] was not fully convinced of removing it in that discussion, but
AFAICS he agrees about moving that functionality to a separate bundle that we
can then clearly label as experimental.
In the current code, the decision to hide a resource based on feature flags is
done in a single place, in the ProviderHandler class:
{code}
Resource getReadableResource ( final ResourceResolverContext ctx, ...){
Resource returnValue = null;
...set returnValue unless resourceAccessSecurity objects...
...and now ctx can decide to hide the resource based on sling:features
return ctx.applyFeatures(returnValue);
}
{code}
So using a service implemented in a different bundle is not a problem, it would
just be used instead of (or inside) the ResourceResolverContext. That service
only needs to know about the Resource and the features services, it doesn't
need any internal knowledge of the resource resolver state.
For now I'll go ahead and remove the sling:features support from the
resourceresolver bundle, and we can later experiment and re-add it with a more
modular design.
Remove sling:features support from the resource resolver, for now
-
Key: SLING-3483
URL: https://issues.apache.org/jira/browse/SLING-3483
Project: Sling
Issue Type: Improvement
Components: ResourceResolver
Affects Versions: Resource Resolver 1.0.6
Reporter: Bertrand Delacretaz
Assignee: Bertrand Delacretaz
Priority: Minor
As discussed on list ( http://markmail.org/message/nuaiox2gkmutttdo ) I
believe the current magic support of the sling:features resource property
in the resource resolver core opens a can of worms in some cases. Carsten
agrees and we'd like to remove that support from the core resource resolver
bundle for now.
[~justinedelson] was not fully convinced of removing it in that discussion,
but AFAICS he agrees about moving that functionality to a separate bundle
that we can then clearly label as experimental.
In the current code, the decision to hide a resource based on feature flags
is done in a single place, in the ProviderHandler class:
Resource getReadableResource ( final ResourceResolverContext ctx, ...){
Resource returnValue = null;
...set returnValue unless resourceAccessSecurity objects...
...and now ctx can decide to hide the resource based on sling:features
return ctx.applyFeatures(returnValue);
}
So using a service implemented in a different bundle is not a problem, it
would just be used instead of (or inside) the ResourceResolverContext. That
service only needs to know about the Resource and the features services, it
doesn't need any internal knowledge of the resource resolver state.
For now I'll go ahead and remove the sling:features support from the
resourceresolver bundle, and we can later experiment and re-add it with a
more modular design.
--
This message was
Re: Removing sling:features support from the resource resolver?
Hi, On Fri, Mar 21, 2014 at 9:49 PM, Carsten Ziegeler cziege...@apache.org wrote: ...Therefore my suggestion is still, let's remove it for now, do a release (of the RR and the feature flags bundle) and then revisit this and do it right I have created https://issues.apache.org/jira/browse/SLING-3483 for the removal, also chatted with Justin who confirms that his -0 means he's not strongly opposed to doing that. -Bertrand
Jenkins build is back to normal : sling-contrib-1.6 » Apache Sling MongoDB Resource Provider #1116
See https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.mongodb/1116/changes
Jenkins build is unstable: sling-contrib-1.6 » Apache Sling Replication Integration Tests #1116
See https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.replication.it/1116/
Build failed in Jenkins: sling-contrib-1.6 » Apache Sling JCR Resource Security #1116
See https://builds.apache.org/job/sling-contrib-1.6/org.apache.sling$org.apache.sling.jcr.resourcesecurity/1116/ -- [INFO] [INFO] [INFO] Building Apache Sling JCR Resource Security 0.0.1-SNAPSHOT [INFO] Downloading: http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.resourceaccesssecurity/0.0.1-SNAPSHOT/maven-metadata.xml Downloading: http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.resourceaccesssecurity/0.0.1-SNAPSHOT/org.apache.sling.resourceaccesssecurity-0.0.1-SNAPSHOT.pom [WARNING] The POM for org.apache.sling:org.apache.sling.resourceaccesssecurity:jar:0.0.1-SNAPSHOT is missing, no dependency information available Downloading: http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.resourceaccesssecurity/0.0.1-SNAPSHOT/org.apache.sling.resourceaccesssecurity-0.0.1-SNAPSHOT.jar [JENKINS] Archiving disabled
Build failed in Jenkins: sling-contrib-1.6 #1116
See https://builds.apache.org/job/sling-contrib-1.6/1116/changes Changes: [rombert] extensions/mongodb: use released versions for dependencies [cziegeler] SLING-3477 : BackgroundHttpServletRequest incompatible with Enging 2.3.0 -- [...truncated 5167 lines...] [INFO] [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ org.apache.sling.jcr.compiler --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/jcr/compiler/src/test/resources [INFO] Copying 3 resources [INFO] [INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ org.apache.sling.jcr.compiler --- [INFO] No sources to compile [INFO] [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ org.apache.sling.jcr.compiler --- [INFO] [JENKINS] Recording test results[INFO] --- animal-sniffer-maven-plugin:1.9:check (default) @ org.apache.sling.jcr.compiler --- [INFO] Checking unresolved references to org.codehaus.mojo.signature:java15:1.0 [INFO] [INFO] --- maven-bundle-plugin:2.4.0:bundle (default-bundle) @ org.apache.sling.jcr.compiler --- [INFO] [INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce-java) @ org.apache.sling.jcr.compiler --- [INFO] [INFO] --- maven-antrun-plugin:1.7:run (set-bundle-required-execution-environment) @ org.apache.sling.jcr.compiler --- [INFO] Executing tasks main: [INFO] Executed tasks [WARNING] Failed to getClass for org.apache.maven.plugin.source.SourceJarMojo [INFO] [INFO] --- maven-source-plugin:2.2.1:jar (attach-sources) @ org.apache.sling.jcr.compiler --- [INFO] Building jar: https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/jcr/compiler/target/org.apache.sling.jcr.compiler-2.1.1-SNAPSHOT-sources.jar [INFO] [INFO] --- maven-site-plugin:3.2:attach-descriptor (attach-descriptor) @ org.apache.sling.jcr.compiler --- [INFO] [INFO] --- ianal-maven-plugin:1.0-alpha-1:verify-legal-files (default) @ org.apache.sling.jcr.compiler --- [INFO] Checking legal files in: org.apache.sling.jcr.compiler-2.1.1-SNAPSHOT.jar [INFO] Checking legal files in: org.apache.sling.jcr.compiler-2.1.1-SNAPSHOT-sources.jar [INFO] [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ org.apache.sling.jcr.compiler --- [INFO] Installing https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/jcr/compiler/target/org.apache.sling.jcr.compiler-2.1.1-SNAPSHOT.jar to /home/jenkins/jenkins-slave/maven-repositories/0/org/apache/sling/org.apache.sling.jcr.compiler/2.1.1-SNAPSHOT/org.apache.sling.jcr.compiler-2.1.1-SNAPSHOT.jar [INFO] Installing https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/jcr/compiler/pom.xml to /home/jenkins/jenkins-slave/maven-repositories/0/org/apache/sling/org.apache.sling.jcr.compiler/2.1.1-SNAPSHOT/org.apache.sling.jcr.compiler-2.1.1-SNAPSHOT.pom [INFO] Installing https://builds.apache.org/job/sling-contrib-1.6/ws/contrib-1.6/jcr/compiler/target/org.apache.sling.jcr.compiler-2.1.1-SNAPSHOT-sources.jar to /home/jenkins/jenkins-slave/maven-repositories/0/org/apache/sling/org.apache.sling.jcr.compiler/2.1.1-SNAPSHOT/org.apache.sling.jcr.compiler-2.1.1-SNAPSHOT-sources.jar [INFO] [INFO] --- maven-bundle-plugin:2.4.0:install (default-install) @ org.apache.sling.jcr.compiler --- [INFO] Local OBR update disabled (enable with -DobrRepository) [JENKINS] Archiving disabled [INFO] [INFO] [INFO] Building Apache Sling JCR Prefs 1.0.1-SNAPSHOT [INFO] [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ org.apache.sling.jcr.prefs --- [INFO] [INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce-java) @ org.apache.sling.jcr.prefs --- [INFO] [INFO] --- maven-antrun-plugin:1.7:run (set-bundle-required-execution-environment) @ org.apache.sling.jcr.prefs --- [INFO] Executing tasks main: [INFO] Executed tasks [INFO] [INFO] --- maven-remote-resources-plugin:1.4:process (default) @ org.apache.sling.jcr.prefs --- [INFO] [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ org.apache.sling.jcr.prefs --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] Copying 0 resource [INFO] Copying 3 resources [INFO] [INFO] --- maven-antrun-plugin:1.7:run (check-memory-task) @ org.apache.sling.jcr.prefs --- [INFO] Executing tasks main: [echo] WARNING (SLING-443/SLING-1782) ** [echo] On most platforms, you'll get OutOfMemoryErrors when building unless you set [echo] on 32bit platforms: MAVEN_OPTS=-Xmx256M -XX:MaxPermSize=256M, see SLING-443 [echo] on 64bit platforms: MAVEN_OPTS=-Xmx512M -XX:MaxPermSize=512M, see SLING-1782 [echo]
Re: Removing sling:features support from the resource resolver?
Hi, On Thu, Mar 27, 2014 at 6:14 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, On Fri, Mar 21, 2014 at 9:49 PM, Carsten Ziegeler cziege...@apache.org wrote: ...Therefore my suggestion is still, let's remove it for now, do a release (of the RR and the feature flags bundle) and then revisit this and do it right I have created https://issues.apache.org/jira/browse/SLING-3483 for the removal, also chatted with Justin who confirms that his -0 means he's not strongly opposed to doing that. Ack. -Bertrand
Re: Jenkins and Buildbot jobs not triggering
Hi, On Wed, Mar 26, 2014 at 5:51 PM, Robert Munteanu robert.munte...@gmail.com wrote: ...I hopefully fixed the Jenkins config but I have no idea what to do about Buildbot. Can someone look into it?... I have created https://issues.apache.org/jira/browse/INFRA-7511 for Buildbot. -Bertrand
[jira] [Resolved] (SLING-3483) Remove sling:features support from the resource resolver, for now
[
https://issues.apache.org/jira/browse/SLING-3483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz resolved SLING-3483.
Resolution: Fixed
sling:features support removed http://svn.apache.org/r1582243
Remove sling:features support from the resource resolver, for now
-
Key: SLING-3483
URL: https://issues.apache.org/jira/browse/SLING-3483
Project: Sling
Issue Type: Improvement
Components: ResourceResolver
Affects Versions: Resource Resolver 1.0.6
Reporter: Bertrand Delacretaz
Assignee: Bertrand Delacretaz
Priority: Minor
As discussed on list ( http://markmail.org/message/nuaiox2gkmutttdo ) I
believe the current magic support of the sling:features resource property
in the resource resolver core opens a can of worms in some cases. Carsten
agrees and we'd like to remove that support from the core resource resolver
bundle for now.
[~justinedelson] was not fully convinced of removing it in that discussion,
but AFAICS he agrees about moving that functionality to a separate bundle
that we can then clearly label as experimental.
In the current code, the decision to hide a resource based on feature flags
is done in a single place, in the ProviderHandler class:
Resource getReadableResource ( final ResourceResolverContext ctx, ...){
Resource returnValue = null;
...set returnValue unless resourceAccessSecurity objects...
...and now ctx can decide to hide the resource based on sling:features
return ctx.applyFeatures(returnValue);
}
So using a service implemented in a different bundle is not a problem, it
would just be used instead of (or inside) the ResourceResolverContext. That
service only needs to know about the Resource and the features services, it
doesn't need any internal knowledge of the resource resolver state.
For now I'll go ahead and remove the sling:features support from the
resourceresolver bundle, and we can later experiment and re-add it with a
more modular design.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Re: Build failed in Jenkins: sling-contrib-1.6 #1116
On Thu, Mar 27, 2014 at 12:28 PM, Apache Jenkins Server jenk...@builds.apache.org wrote: [INFO] [INFO] Building Apache Sling JCR Resource Security 0.0.1-SNAPSHOT [INFO] Downloading: http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.resourceaccesssecurity/0.0.1-SNAPSHOT/maven-metadata.xml Downloading: http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.resourceaccesssecurity/0.0.1-SNAPSHOT/org.apache.sling.resourceaccesssecurity-0.0.1-SNAPSHOT.pom [WARNING] The POM for org.apache.sling:org.apache.sling.resourceaccesssecurity:jar:0.0.1-SNAPSHOT is missing, no dependency information available Downloading: http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.resourceaccesssecurity/0.0.1-SNAPSHOT/org.apache.sling.resourceaccesssecurity-0.0.1-SNAPSHOT.jar [JENKINS] Archiving disabled [INFO] -- Can someone please deploy a SNAPSHOT of the org.apache.sling.resourceaccesssecurity bundle to the Apache maven repo? This would unblock the contrib build. Thanks, Robert -- http://robert.muntea.nu/
[jira] [Created] (SLING-3484) Remove FeatureAuthenticationInfoPostProcessor and FeatureConstants, unneeded
Bertrand Delacretaz created SLING-3484: -- Summary: Remove FeatureAuthenticationInfoPostProcessor and FeatureConstants, unneeded Key: SLING-3484 URL: https://issues.apache.org/jira/browse/SLING-3484 Project: Sling Issue Type: Improvement Components: Feature Flags Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor These classes are not needed anymore due to SLING-3483 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (SLING-3484) Remove FeatureAuthenticationInfoPostProcessor and FeatureConstants, unneeded
[ https://issues.apache.org/jira/browse/SLING-3484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz resolved SLING-3484. Resolution: Fixed Removed both classes in revision 1582249 Remove FeatureAuthenticationInfoPostProcessor and FeatureConstants, unneeded Key: SLING-3484 URL: https://issues.apache.org/jira/browse/SLING-3484 Project: Sling Issue Type: Improvement Components: Feature Flags Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor These classes are not needed anymore due to SLING-3483 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3043) Allow regexp filtering of vanity paths
[ https://issues.apache.org/jira/browse/SLING-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-3043: Fix Version/s: Resource Resolver 1.1.0 Allow regexp filtering of vanity paths -- Key: SLING-3043 URL: https://issues.apache.org/jira/browse/SLING-3043 Project: Sling Issue Type: Bug Components: ResourceResolver Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Labels: vanity Fix For: Resource Resolver 1.1.0 Right now a sling:vanityPath can appear anywhere in the resource tree and it can point to any other location in the tree. In some cases, it's helpful to limit the possibilities. Therefore we should add regexps to exclude certain parts in the tree for scanning and another set of regexps for filtering the location -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (SLING-3482) Synthetic resources should lead to a 404
[
https://issues.apache.org/jira/browse/SLING-3482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved SLING-3482.
-
Resolution: Fixed
If I'm not mistaken we can remove the above block completely.
In the case of a script in the resource tree, the parent path exists and is
readable and in the case of a servlet resource, a provider entry for the parent
exists and has more than a single entry
Synthetic resources should lead to a 404
Key: SLING-3482
URL: https://issues.apache.org/jira/browse/SLING-3482
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Resolver 1.0.6
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
Fix For: Resource Resolver 1.1.0
If e.g. /libs is requested by a user who does not have access to /libs, a
synthetic resource for libs is returned which is then rendered.
This is due to the special handling for servlet resources which are mounted
at /libs/
I think the code in ResourceProviderEntry#getInternalResource is too generic:
if (entries.size() 0 entries.size() == elements.length) {
if (entries.get(entries.size() -
1).getResourceProviders().length == 0) {
logger.debug(Resolved Synthetic {}, fullPath);
return new SyntheticResource(resourceResolver, fullPath,
ResourceProvider.RESOURCE_TYPE_SYNTHETIC);
}
}
However, fixing this might break other parts like the servlet resolver
relying on it
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (SLING-3043) Allow regexp filtering of vanity paths
[ https://issues.apache.org/jira/browse/SLING-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-3043: --- Assignee: Carsten Ziegeler Allow regexp filtering of vanity paths -- Key: SLING-3043 URL: https://issues.apache.org/jira/browse/SLING-3043 Project: Sling Issue Type: Bug Components: ResourceResolver Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Labels: vanity Fix For: Resource Resolver 1.1.0 Right now a sling:vanityPath can appear anywhere in the resource tree and it can point to any other location in the tree. In some cases, it's helpful to limit the possibilities. Therefore we should add regexps to exclude certain parts in the tree for scanning and another set of regexps for filtering the location -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3043) Allow regexp filtering of vanity paths
[ https://issues.apache.org/jira/browse/SLING-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949161#comment-13949161 ] Carsten Ziegeler commented on SLING-3043: - In general, the idea is to get away with vanity paths stored in the resource tree but rely solely on /etc/maps. However, to solve today's problems (until the above is in place), it makes sense to have a whitelist from where vanity paths are read. This can simply be prefixes Allow regexp filtering of vanity paths -- Key: SLING-3043 URL: https://issues.apache.org/jira/browse/SLING-3043 Project: Sling Issue Type: Bug Components: ResourceResolver Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Labels: vanity Fix For: Resource Resolver 1.1.0 Right now a sling:vanityPath can appear anywhere in the resource tree and it can point to any other location in the tree. In some cases, it's helpful to limit the possibilities. Therefore we should add regexps to exclude certain parts in the tree for scanning and another set of regexps for filtering the location -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [VOTE] Release Apache Sling Installer Factory Configuration 1.0.12
Anyone else? 2014-03-24 10:56 GMT+01:00 Chetan Mehrotra chetan.mehro...@gmail.com: +1 (non binding) Chetan Mehrotra On Mon, Mar 24, 2014 at 2:52 PM, Oliver Lietz apa...@oliverlietz.de wrote: On Sunday 23 March 2014 12:00:09 Carsten Ziegeler wrote: Hi, this vote is about the release of Apache Sling Installer Factory Configuration 1.0.12 +1 O. -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release Apache Sling Parent POM 19
Anyone else? 2014-03-24 14:33 GMT+01:00 Carsten Ziegeler cziege...@apache.org: +1 2014-03-24 14:32 GMT+01:00 Carsten Ziegeler cziege...@apache.org: Hi, this vote is about the release of Apache Sling Parent POM 19 Change List: https://issues.apache.org/jira/browse/SLING/fixforversion/12324982 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1043 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1043 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards Carsten -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release Apache Sling Servlets Resolver 2.3.2
Anyone else? 2014-03-24 20:26 GMT+01:00 Oliver Lietz apa...@oliverlietz.de: On Monday 24 March 2014 11:54:39 Carsten Ziegeler wrote: Hi, this vote is about the release of Apache Sling Servlets Resolver 2.3.2 +1 O. -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release Apache Sling Servlets Get 2.1.8
Anyone else? 2014-03-24 20:26 GMT+01:00 Oliver Lietz apa...@oliverlietz.de: On Monday 24 March 2014 11:55:59 Carsten Ziegeler wrote: Hi, this vote is about the release of Apache Sling Servlets Get 2.1.8 +1 O. -- Carsten Ziegeler cziege...@apache.org
[jira] [Updated] (SLING-3043) Allow white list filtering of vanity paths
[ https://issues.apache.org/jira/browse/SLING-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-3043: Summary: Allow white list filtering of vanity paths (was: Allow regexp filtering of vanity paths) Allow white list filtering of vanity paths -- Key: SLING-3043 URL: https://issues.apache.org/jira/browse/SLING-3043 Project: Sling Issue Type: Bug Components: ResourceResolver Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Labels: vanity Fix For: Resource Resolver 1.1.0 Right now a sling:vanityPath can appear anywhere in the resource tree and it can point to any other location in the tree. In some cases, it's helpful to limit the possibilities. Therefore we should add regexps to exclude certain parts in the tree for scanning and another set of regexps for filtering the location -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (SLING-3043) Allow white list filtering of vanity paths
[ https://issues.apache.org/jira/browse/SLING-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-3043. - Resolution: Fixed I've added a configurable whitelist of prefixes from which vanity paths are loaded Allow white list filtering of vanity paths -- Key: SLING-3043 URL: https://issues.apache.org/jira/browse/SLING-3043 Project: Sling Issue Type: Bug Components: ResourceResolver Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Labels: vanity Fix For: Resource Resolver 1.1.0 Right now a sling:vanityPath can appear anywhere in the resource tree and it can point to any other location in the tree. In some cases, it's helpful to limit the possibilities. Therefore we should add regexps to exclude certain parts in the tree for scanning and another set of regexps for filtering the location -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SLING-3464) The DynamicClassLoaderManager doesn't reload classes when a bundle transitions from ACTIVE to RESOLVED
[ https://issues.apache.org/jira/browse/SLING-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-3464: Summary: The DynamicClassLoaderManager doesn't reload classes when a bundle transitions from ACTIVE to RESOLVED (was: The DynamicClassLoaderManager doesn't reload classes when a bundle transitions from STARTED to RESOLVED) The DynamicClassLoaderManager doesn't reload classes when a bundle transitions from ACTIVE to RESOLVED -- Key: SLING-3464 URL: https://issues.apache.org/jira/browse/SLING-3464 Project: Sling Issue Type: Bug Components: Commons Affects Versions: Commons ClassLoader 1.3.0 Reporter: Radu Cotescu Fix For: Commons ClassLoader 1.3.2 The bundle activator from org.apache.sling.commons.classloader also acts as a SynchronousBundleListener, taking care to clean the DynamicClassLoaderManager (DCLM) when a bundle changes its state. However, the DCLM doesn't get cleaned when a bundle transitions from ACTIVE to RESOLVED, which is inconsistent: for example no services will be resolved from that bundle, however classes already loaded through DCLM will get solved. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3203) Post servlet's delete operation deletes parent of nonexisting node
[ https://issues.apache.org/jira/browse/SLING-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949279#comment-13949279 ] Rob Ryan commented on SLING-3203: - In the case an :applyTo is provided isn't this check too draconian? Forbidding selectors on the sling post servlet ignores that filters and security checks might wish to use selectors to enforce security in front of the sling post servlet. Post servlet's delete operation deletes parent of nonexisting node -- Key: SLING-3203 URL: https://issues.apache.org/jira/browse/SLING-3203 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Post 2.3.2 Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Fix For: Servlets Post 2.3.4 Attachments: SLING-3203.patch In the below scenario, /tmp/test is gone after the delete operation - the resource resolver goes up the path of the nonexisting node, and it's /tmp/test that's provided to the DeleteOperation. I think we should change this (maybe with a backwards compatibility switch), as it's clear that the user's intention in this case is not to delete /tmp/test. Maybe just reject :delete operations if the request has any selector or extensions. curl -u admin:admin -X POST http://localhost:8080/tmp/test/some.node curl -u admin:admin http://localhost:8080/tmp/test.tidy.2.json # looks good curl -u admin:admin -F:operation=delete http://localhost:8080/tmp/test.other/nothing curl -u admin:admin http://localhost:8080/tmp/test.tidy.2.json # 404 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3464) The DynamicClassLoaderManager doesn't reload classes when a bundle transitions from ACTIVE to RESOLVED
[ https://issues.apache.org/jira/browse/SLING-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949296#comment-13949296 ] Carsten Ziegeler commented on SLING-3464: - I'Ve committed a potential fix for the problem The DynamicClassLoaderManager doesn't reload classes when a bundle transitions from ACTIVE to RESOLVED -- Key: SLING-3464 URL: https://issues.apache.org/jira/browse/SLING-3464 Project: Sling Issue Type: Bug Components: Commons Affects Versions: Commons ClassLoader 1.3.0 Reporter: Radu Cotescu Assignee: Carsten Ziegeler Fix For: Commons ClassLoader 1.3.2 The bundle activator from org.apache.sling.commons.classloader also acts as a SynchronousBundleListener, taking care to clean the DynamicClassLoaderManager (DCLM) when a bundle changes its state. However, the DCLM doesn't get cleaned when a bundle transitions from ACTIVE to RESOLVED, which is inconsistent: for example no services will be resolved from that bundle, however classes already loaded through DCLM will get solved. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SLING-3481) AbstractSlingRepository2.login().getRepository() not symmetric
[ https://issues.apache.org/jira/browse/SLING-3481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949314#comment-13949314 ] Carsten Ziegeler commented on SLING-3481: - As this just fixes some places but not all, I think it's not worth the effort. My feeling is that we rather should remove the proxy alltogether as this is usually not required at all, it's more a theoretical approach AbstractSlingRepository2.login().getRepository() not symmetric -- Key: SLING-3481 URL: https://issues.apache.org/jira/browse/SLING-3481 Project: Sling Issue Type: Bug Components: General Affects Versions: JCR Base 2.2.2 Reporter: Tobias Bocanegra Priority: Minor Fix For: JCR Base 2.2.4 Attachments: SLING-3481.r1582018..patch the AbstractSlingRepository2.login() returns a session, which does not return the same repository object in 'getRepository()'. -- This message was sent by Atlassian JIRA (v6.2#6252)
[VOTE] Release Apache Sling discovery.impl 1.0.6
Hi, We solved 1 issue in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12326448 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1044/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1044 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. My (new) public key is on its way to https://people.apache.org/keys/group/sling.asc but can already be verified here: http://pgp.mit.edu/pks/lookup?op=vindexsearch=0x0C18A8201E60C54E Cheers, Stefan
Re: [VOTE] Release Apache Sling discovery.impl 1.0.6
+1 Carsten 2014-03-27 16:33 GMT+01:00 Stefan Egli e...@adobe.com: Hi, We solved 1 issue in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12326448 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1044/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1044 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. My (new) public key is on its way to https://people.apache.org/keys/group/sling.asc but can already be verified here: http://pgp.mit.edu/pks/lookup?op=vindexsearch=0x0C18A8201E60C54E Cheers, Stefan -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release Apache Sling Parent POM 19
Hi, On Mon, Mar 24, 2014 at 2:32 PM, Carsten Ziegeler cziege...@apache.org wrote: Apache Sling Parent POM 19 ... Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1043 ... +1, checked signatures and that the below archives matches its svn tag. MD5 (sling-19-source-release.zip) = f1e5ba5620762e957efc9d5d393ab032 -Bertrand
[jira] [Commented] (SLING-3481) AbstractSlingRepository2.login().getRepository() not symmetric
[
https://issues.apache.org/jira/browse/SLING-3481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949616#comment-13949616
]
Tobias Bocanegra commented on SLING-3481:
-
Well, the problem is not only in the proxy but with all classes that decorate a
JCR interface.
I don't know what the best pattern is - should they always returns decorators
so that the symmetry is preserved?
the JCR javadoc is a big vague here, if the same == identical object should
be returned in the reverse methods, eg:
http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/Item.html#getSession():
{quote}
Returns the Session through which this Item was acquired.
{quote}
and:
http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/Session.html#getRepository()
{quote}
Returns the Repository object through which this session was acquired.
{quote}
If you take the javadoc literally, I think the contract indeed is, that the
identical object needs to be returned. So a compliant implementation should
ensure that all returned objects are properly decorated, so that they can
return the original session and/or repository.
AbstractSlingRepository2.login().getRepository() not symmetric
--
Key: SLING-3481
URL: https://issues.apache.org/jira/browse/SLING-3481
Project: Sling
Issue Type: Bug
Components: General
Affects Versions: JCR Base 2.2.2
Reporter: Tobias Bocanegra
Priority: Minor
Fix For: JCR Base 2.2.4
Attachments: SLING-3481.r1582018..patch
the AbstractSlingRepository2.login() returns a session, which does not return
the same repository object in 'getRepository()'.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
