[jira] [Commented] (SLING-2710) Define TenantManager API
[
https://issues.apache.org/jira/browse/SLING-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13590318#comment-13590318
]
Felix Meschberger commented on SLING-2710:
--
Committed a first implementation in Rev. 1451514.
Unit tests and potential fixes following.
Define TenantManager API
Key: SLING-2710
URL: https://issues.apache.org/jira/browse/SLING-2710
Project: Sling
Issue Type: New Feature
Components: Extensions
Reporter: Felix Meschberger
Assignee: Felix Meschberger
Fix For: Tenant 1.0
Attachments: SLING-2710-2.patch, SLING-2710.patch
Tenants currently can only be administered (create, update, remove) through
the Web Console. In addition the TenantProvider service interface allows for
looking tenants up (read).
For administrative purposes it would be good to have a TenantManager service
interface which allows for these administrative tasks. Something like:
public interface TenantManager extends TenantProvider {
Tenant create(String tenantId, MapString, Object properties);
void setProperty(Tenant tenant, String name, Object value);
void remove(Tenant tenant);
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: sling pull request: SLING-2707 Support of chunked file upload into Sling
Hi Thanks for the pull request. I have the impression, I prefer patches attached to the respective Sling issue for better recording. WDOT ? Regards Felix Am 28.02.2013 um 17:02 schrieb shashank-itbhu: GitHub user shashank-itbhu opened a pull request: https://github.com/apache/sling/pull/1 SLING-2707 Support of chunked file upload into Sling Feature enhance with details at https://cwiki.apache.org/confluence/display/SLING/Chunked+File+Upload+Support 1. Extension to [SlingPostServlet|http://sling.apache.org/site/manipulating-content-the-slingpostservlet-servletspost.html] 2. Chunk upload is supported in modifyoperation of [SlingPostServlet|http://sling.apache.org/site/manipulating-content-the-slingpostservlet-servletspost.html] ( ie. In default operation) . No new operation introduced for it 3. Chunks are saved in temporary location identified by upload id 4. Chunk processing * First/Intermediate chunks: Chunk is saved in temporary location in jcr. Ignores all upload semantics (@TypeHint, etc) and request parameters. * Last chunk: Stitches all chunks. Process all upload semantics and request parameters and creates jcr node structure at the right location. You can merge this pull request into a Git repository by running: $ git pull https://github.com/shashank-itbhu/sling trunk Alternatively you can review and apply these changes as the patch at: https://github.com/apache/sling/pull/1.patch commit 1a3b17d498bf8781dab7ffcfffce3335e00dad72 Author: Shashank Gupta shgu...@adobe.com Date: 2013-02-28T15:59:42Z SLING-2707 Support of chunked file upload into Sling Feature enhance with details at https://cwiki.apache.org/confluence/display/SLING/Chunked+File+Upload+Support 1. Extension to [SlingPostServlet|http://sling.apache.org/site/manipulating-content-the-slingpostservlet-servletspost.html] 2. Chunk upload is supported in modifyoperation of [SlingPostServlet|http://sling.apache.org/site/manipulating-content-the-slingpostservlet-servletspost.html] ( ie. In default operation) . No new operation introduced for it 3. Chunks are saved in temporary location identified by upload id 4. Chunk processing * First/Intermediate chunks: Chunk is saved in temporary location in jcr. Ignores all upload semantics (@TypeHint, etc) and request parameters. * Last chunk: Stitches all chunks. Process all upload semantics and request parameters and creates jcr node structure at the right location. -- Felix Meschberger | Principal Scientist | Adobe
[jira] [Commented] (SLING-2760) org.apache.sling.auth.openid bundle has dependencies not available on Maven central
[
https://issues.apache.org/jira/browse/SLING-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13590336#comment-13590336
]
Felix Meschberger commented on SLING-2760:
--
Sounds like a good option to me.
org.apache.sling.auth.openid bundle has dependencies not available on Maven
central
---
Key: SLING-2760
URL: https://issues.apache.org/jira/browse/SLING-2760
Project: Sling
Issue Type: Bug
Components: Authentication
Affects Versions: OpenID Authentication 1.0.2
Reporter: Robert Munteanu
Priority: Minor
The org.apache.sling.auth.openid bundle includes the following repository
definition in its pom.xml file
{code}repositories
repository
releases
enabledtrue/enabled
/releases
iddyuproject-repo/id
namedyuproject-repo/name
urlhttp://dyuproject.googlecode.com/svn/repos/maven2/url
/repository
/repositories
{code}
and the following dependencies
{code}
dependency
groupIdcom.dyuproject/groupId
artifactIddyuproject-openid/artifactId
version1.1.7/version
/dependency
dependency
groupIdcom.dyuproject/groupId
artifactIddyuproject-util/artifactId
version1.1.7/version
/dependency
dependency
groupIdcom.dyuproject/groupId
artifactIddyuproject-json/artifactId
version1.1.7/version
/dependency
{code}
Since we sync/upload these artifacts to maven central [1] we should consider
following the recommendation of not adding repositories to POMs [2] . There
is an open request in the dyuproject tracker [3] to upload the openid
artifacts to Maven Central, but it's been there for almost two years, and the
project hasn't seen much activity ( no commits since June 2011 ).
I see two ways around this issue:
- Use the sonatype service for uploading 3rd party bundles to Maven Central
[4]
- Replace the com.dyuproject dependency with something different
Thoughts?
[1]: http://search.maven.org/#search|ga|1|org.apache.sling.auth.openid
[2]:
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-6.CentralSyncRequirement
[3]: http://code.google.com/p/dyuproject/issues/detail?id=32
[4]:
https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+The+Central+Repository
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2760) org.apache.sling.auth.openid bundle has dependencies not available on Maven central
[
https://issues.apache.org/jira/browse/SLING-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13590337#comment-13590337
]
Robert Munteanu commented on SLING-2760:
Dear sender,
I am out of office until the 4th of March with limited access to email. I will
reply to your email once I return.
Regards,
Robert Munteanu
org.apache.sling.auth.openid bundle has dependencies not available on Maven
central
---
Key: SLING-2760
URL: https://issues.apache.org/jira/browse/SLING-2760
Project: Sling
Issue Type: Bug
Components: Authentication
Affects Versions: OpenID Authentication 1.0.2
Reporter: Robert Munteanu
Priority: Minor
The org.apache.sling.auth.openid bundle includes the following repository
definition in its pom.xml file
{code}repositories
repository
releases
enabledtrue/enabled
/releases
iddyuproject-repo/id
namedyuproject-repo/name
urlhttp://dyuproject.googlecode.com/svn/repos/maven2/url
/repository
/repositories
{code}
and the following dependencies
{code}
dependency
groupIdcom.dyuproject/groupId
artifactIddyuproject-openid/artifactId
version1.1.7/version
/dependency
dependency
groupIdcom.dyuproject/groupId
artifactIddyuproject-util/artifactId
version1.1.7/version
/dependency
dependency
groupIdcom.dyuproject/groupId
artifactIddyuproject-json/artifactId
version1.1.7/version
/dependency
{code}
Since we sync/upload these artifacts to maven central [1] we should consider
following the recommendation of not adding repositories to POMs [2] . There
is an open request in the dyuproject tracker [3] to upload the openid
artifacts to Maven Central, but it's been there for almost two years, and the
project hasn't seen much activity ( no commits since June 2011 ).
I see two ways around this issue:
- Use the sonatype service for uploading 3rd party bundles to Maven Central
[4]
- Replace the com.dyuproject dependency with something different
Thoughts?
[1]: http://search.maven.org/#search|ga|1|org.apache.sling.auth.openid
[2]:
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-6.CentralSyncRequirement
[3]: http://code.google.com/p/dyuproject/issues/detail?id=32
[4]:
https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+The+Central+Repository
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Monitoring and Statistics
Hi,
I agree with Felix here - we should have a coherent story here and JMX
looks like a good solution to me as well. As outlined in the post that
started this thread, using JMX from an implementation pov is pretty
simple.
So are there any concerns or problems for using JMX from a client pov?
No REST interface is not really an issue and I guess it would be easy
to write a JMX over REST bridge :)
Regards
Carsten
2013/3/1 Felix Meschberger fmesc...@adobe.com:
Hi
I really appreciate this discussion. But I would like to get to a point where
we create a proper future-proof (as much as possible) architecture which
properly integrates with the current situation:
* JMX is the system of choice for systems management
* The Web Console is the respective system of choice
for web based interactive tooling
* Don't reinvent wheels
I would really like to highlight the last point: I would prefer to reuse
existing functionality and libraries as much as possible instead of
reinventing our own stuff using yet another channel.
Regards
Felix
Am 22.02.2013 um 23:59 schrieb Ian Boston:
Hi,
Whilst writing the MBeans in the event bundle I started thinking about
monitoring inside Sling. IMHO there are not enough to really know what
a instance under load is doing. Much though I like JMX it comes with
implementation and runtime overhead which I don't much like.
Runtime:
* Running with JMX enabled doesn't add any overhead, but once a client
is connected there is some (some reports upto 3% of resources).
* You have to remember to enable it, and most of the time JVMs are not
enabled. By the time you really need it, its often too late.
* JMX is not restful.
Implementation
* MBeans are not that hard to implement with the OSGi Whiteboard, but
they have to be implemented.
Alternatives.
In Jackarabbit there is/was a statistics class [1], which IIUC uses
counters and time series stored in a map. The service can then be
queries to extract the values by wrapping in an MBean or Servlet.
I think the approach could be generalised and extended so that
anything in the container could use the service to record metrics. The
api might look something like
public interface Statistics {
/**
* Increment a counter by 1
*/
void increment(String counterName);
/**
* Record a double value in a timeseries.
*/
void record(String timeSeriesName, double value);
/**
* Record a long value in a timeseries.
*/
void record(String timeSeriesName, long value);
}
and (so that any reference can be optional on a service
implementation, the final is a hint to hotspot to inline)
public final class StatisticsUtils {
private StatisticsUtils() {
}
public static void increment(Statistics statistics, String counterName) {
if ( statistics != null ) {
statistics.increment(counterName);
}
}
... etc for the other methods ..
}
The service would need to deal with all the implementation details
(including concurrency and speed). The service implementation would
also come with a servlet endpoint (under /system/*) and/or single JMX
MBean.
Anything that wanted to record stats would then bind to the service
and use it. I think this would avoid the issues mentioned above with
wide scale MBean usage.
WDYT?
(apologies for the noise if this already exists, and if so, please
treat it as a question: where and how do we record stats?)
Ian
1 http://wiki.apache.org/jackrabbit/Statistics
--
Felix Meschberger | Principal Scientist | Adobe
--
Carsten Ziegeler
cziege...@apache.org
[jira] [Updated] (SLING-2761) JcrResourceProvider.create should filter protected properties
[ https://issues.apache.org/jira/browse/SLING-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-2761: Fix Version/s: JCR Resource 2.2.6 JcrResourceProvider.create should filter protected properties - Key: SLING-2761 URL: https://issues.apache.org/jira/browse/SLING-2761 Project: Sling Issue Type: Bug Components: JCR Affects Versions: JCR Resource 2.2.4 Reporter: Alex Parvulescu Assignee: Carsten Ziegeler Fix For: JCR Resource 2.2.6 While running some of the integration tests using Oak as a repository impl, I ran into some ConstraintViolationExceptions with the PostServletVersionableTest. This uncovered an issue in Jackrabbit JCR-3526 where you can change protected properties on new items, which is in fact considered illegal. Coming back to the PostServletVersionableTest, the test setup uses this trick to set up the content and I think it should be changed. On a more general note fixing JCR-3526 could turn up even more problems that the aforementioned test, so it would be nice to have some more thoughts on this on how big the problem could really be. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Monitoring and Statistics
Hi,
Ok, I can see you dont like the concept.
I'll abandon it and use JMX beans in each bundle where appropriate,
which for anyone deploying in a cluster to be monitored will require
local monitoring scripts like OmniTI's Jezebel, Munins JMX plugin or
Splunks JMX plugin.
BTW the idea for the approach (central monitoring simple counters and
values delivered over http rather than JMX) comes from the Resmon
protocol used bu OmniTI as the native protocol for Reconnoiter. If you
are interested you can read goals of that system[1] or the a rant[2],
which is a bit at the extreem end of the spectrum, and its probably
valid to say not relevant for Sling. BTW2: I dont want to reinvent
Reconnoiter or exclusively bind to it, bit I would have like to feed
it and its competitors efficiently with minimal impact or OS level
configuration on each deployed instance.
Best Regards
Ian
1 http://labs.omniti.com/labs/reconnoiter/wiki/Goals
2 http://lethargy.org/~jesus/writes/reconnoiter-and-another-platform
On 1 March 2013 18:51, Felix Meschberger fmesc...@adobe.com wrote:
Hi
I really appreciate this discussion. But I would like to get to a point where
we create a proper future-proof (as much as possible) architecture which
properly integrates with the current situation:
* JMX is the system of choice for systems management
* The Web Console is the respective system of choice
for web based interactive tooling
* Don't reinvent wheels
I would really like to highlight the last point: I would prefer to reuse
existing functionality and libraries as much as possible instead of
reinventing our own stuff using yet another channel.
Regards
Felix
Am 22.02.2013 um 23:59 schrieb Ian Boston:
Hi,
Whilst writing the MBeans in the event bundle I started thinking about
monitoring inside Sling. IMHO there are not enough to really know what
a instance under load is doing. Much though I like JMX it comes with
implementation and runtime overhead which I don't much like.
Runtime:
* Running with JMX enabled doesn't add any overhead, but once a client
is connected there is some (some reports upto 3% of resources).
* You have to remember to enable it, and most of the time JVMs are not
enabled. By the time you really need it, its often too late.
* JMX is not restful.
Implementation
* MBeans are not that hard to implement with the OSGi Whiteboard, but
they have to be implemented.
Alternatives.
In Jackarabbit there is/was a statistics class [1], which IIUC uses
counters and time series stored in a map. The service can then be
queries to extract the values by wrapping in an MBean or Servlet.
I think the approach could be generalised and extended so that
anything in the container could use the service to record metrics. The
api might look something like
public interface Statistics {
/**
* Increment a counter by 1
*/
void increment(String counterName);
/**
* Record a double value in a timeseries.
*/
void record(String timeSeriesName, double value);
/**
* Record a long value in a timeseries.
*/
void record(String timeSeriesName, long value);
}
and (so that any reference can be optional on a service
implementation, the final is a hint to hotspot to inline)
public final class StatisticsUtils {
private StatisticsUtils() {
}
public static void increment(Statistics statistics, String counterName) {
if ( statistics != null ) {
statistics.increment(counterName);
}
}
... etc for the other methods ..
}
The service would need to deal with all the implementation details
(including concurrency and speed). The service implementation would
also come with a servlet endpoint (under /system/*) and/or single JMX
MBean.
Anything that wanted to record stats would then bind to the service
and use it. I think this would avoid the issues mentioned above with
wide scale MBean usage.
WDYT?
(apologies for the noise if this already exists, and if so, please
treat it as a question: where and how do we record stats?)
Ian
1 http://wiki.apache.org/jackrabbit/Statistics
--
Felix Meschberger | Principal Scientist | Adobe
[jira] [Created] (SLING-2762) AbstractSlingRepository#login violates JCR spec
Antonio Sanso created SLING-2762:
Summary: AbstractSlingRepository#login violates JCR spec
Key: SLING-2762
URL: https://issues.apache.org/jira/browse/SLING-2762
Project: Sling
Issue Type: Bug
Components: JCR
Reporter: Antonio Sanso
AbstractSlingRepository#login seems to violate the javax.jcr.Repository spec.
The API [0] says
If credentials is null, it is assumed that authentication is handled by a
mechanism external to the repository itself (for example, through the JAAS
framework) and that the repository implementation exists within a context (for
example, an application server) that allows it to handle authorization of the
request for access to the specified workspace.
while the implementation looks like
{code}
...
if (credentials == null) {
credentials = getAnonCredentials(this.anonUser);
}
...
{code}
[0]
http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/Repository.html#login%28javax.jcr.Credentials,%20java.lang.String%29
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Monitoring and Statistics
On 1 March 2013 20:17, Carsten Ziegeler cziege...@apache.org wrote:
Hi,
I agree with Felix here - we should have a coherent story here and JMX
looks like a good solution to me as well. As outlined in the post that
started this thread, using JMX from an implementation pov is pretty
simple.
To be honest extending StandardMBean is not the issue. Doing it in a
way thats safe and low impact is, as you pointed out when talking
about earlier attempts to generate stats. If each bundle has its own
implementation we will re-invent the wheel, and getting even simple
counters right with no synchronisation is not as simple as volatile
int x; i++; Its not hard by has to be done in the right way.
So are there any concerns or problems for using JMX from a client pov?
Depends on who you talk to.
Most sysops people dont like JMX due to the cost of querying it and
most java devs do like it because it has GUI tools. Most sysops tools
have bridges that spin up a JVM, query JMX and convert the stats into
some other format, (Resmon XML, RRDTool). That uses a minimum of 64MB
of RAM and sysops people tend to get a bit agitated by that when they
compare it to what a python/bash/c command uses.
No REST interface is not really an issue and I guess it would be easy
to write a JMX over REST bridge :)
It would and it could live in a separate optional bundle for anyone
that wanted it and I could write a JMX Bean ontop of the map as I did
for the Jackrabbit RepositoryStatistics
Best Regards
Ian
Regards
Carsten
2013/3/1 Felix Meschberger fmesc...@adobe.com:
Hi
I really appreciate this discussion. But I would like to get to a point
where we create a proper future-proof (as much as possible) architecture
which properly integrates with the current situation:
* JMX is the system of choice for systems management
* The Web Console is the respective system of choice
for web based interactive tooling
* Don't reinvent wheels
I would really like to highlight the last point: I would prefer to reuse
existing functionality and libraries as much as possible instead of
reinventing our own stuff using yet another channel.
Regards
Felix
Am 22.02.2013 um 23:59 schrieb Ian Boston:
Hi,
Whilst writing the MBeans in the event bundle I started thinking about
monitoring inside Sling. IMHO there are not enough to really know what
a instance under load is doing. Much though I like JMX it comes with
implementation and runtime overhead which I don't much like.
Runtime:
* Running with JMX enabled doesn't add any overhead, but once a client
is connected there is some (some reports upto 3% of resources).
* You have to remember to enable it, and most of the time JVMs are not
enabled. By the time you really need it, its often too late.
* JMX is not restful.
Implementation
* MBeans are not that hard to implement with the OSGi Whiteboard, but
they have to be implemented.
Alternatives.
In Jackarabbit there is/was a statistics class [1], which IIUC uses
counters and time series stored in a map. The service can then be
queries to extract the values by wrapping in an MBean or Servlet.
I think the approach could be generalised and extended so that
anything in the container could use the service to record metrics. The
api might look something like
public interface Statistics {
/**
* Increment a counter by 1
*/
void increment(String counterName);
/**
* Record a double value in a timeseries.
*/
void record(String timeSeriesName, double value);
/**
* Record a long value in a timeseries.
*/
void record(String timeSeriesName, long value);
}
and (so that any reference can be optional on a service
implementation, the final is a hint to hotspot to inline)
public final class StatisticsUtils {
private StatisticsUtils() {
}
public static void increment(Statistics statistics, String counterName) {
if ( statistics != null ) {
statistics.increment(counterName);
}
}
... etc for the other methods ..
}
The service would need to deal with all the implementation details
(including concurrency and speed). The service implementation would
also come with a servlet endpoint (under /system/*) and/or single JMX
MBean.
Anything that wanted to record stats would then bind to the service
and use it. I think this would avoid the issues mentioned above with
wide scale MBean usage.
WDYT?
(apologies for the noise if this already exists, and if so, please
treat it as a question: where and how do we record stats?)
Ian
1 http://wiki.apache.org/jackrabbit/Statistics
--
Felix Meschberger | Principal Scientist | Adobe
--
Carsten Ziegeler
cziege...@apache.org
[jira] [Commented] (SLING-2761) JcrResourceProvider.create should filter protected properties
[ https://issues.apache.org/jira/browse/SLING-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13590388#comment-13590388 ] Carsten Ziegeler commented on SLING-2761: - I've fixed the problem, the properties are now checked and handled correctly. (I created a new utility class to avoid duplicate code) JcrResourceProvider.create should filter protected properties - Key: SLING-2761 URL: https://issues.apache.org/jira/browse/SLING-2761 Project: Sling Issue Type: Bug Components: JCR Affects Versions: JCR Resource 2.2.4 Reporter: Alex Parvulescu Assignee: Carsten Ziegeler Fix For: JCR Resource 2.2.6 While running some of the integration tests using Oak as a repository impl, I ran into some ConstraintViolationExceptions with the PostServletVersionableTest. This uncovered an issue in Jackrabbit JCR-3526 where you can change protected properties on new items, which is in fact considered illegal. Coming back to the PostServletVersionableTest, the test setup uses this trick to set up the content and I think it should be changed. On a more general note fixing JCR-3526 could turn up even more problems that the aforementioned test, so it would be nice to have some more thoughts on this on how big the problem could really be. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SLING-2761) JcrResourceProvider.create should filter protected properties
[ https://issues.apache.org/jira/browse/SLING-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-2761. - Resolution: Fixed JcrResourceProvider.create should filter protected properties - Key: SLING-2761 URL: https://issues.apache.org/jira/browse/SLING-2761 Project: Sling Issue Type: Bug Components: JCR Affects Versions: JCR Resource 2.2.4 Reporter: Alex Parvulescu Assignee: Carsten Ziegeler Fix For: JCR Resource 2.2.6 While running some of the integration tests using Oak as a repository impl, I ran into some ConstraintViolationExceptions with the PostServletVersionableTest. This uncovered an issue in Jackrabbit JCR-3526 where you can change protected properties on new items, which is in fact considered illegal. Coming back to the PostServletVersionableTest, the test setup uses this trick to set up the content and I think it should be changed. On a more general note fixing JCR-3526 could turn up even more problems that the aforementioned test, so it would be nice to have some more thoughts on this on how big the problem could really be. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Apache Sling Launchpad Base 2.5.0 and Apache Sling Scripting Console 1.0.0
+1 Regards Felix Am 27.02.2013 um 11:28 schrieb Carsten Ziegeler: Hi, this vote is about a long outstanding release of launchpad base and a new module, the scripting console So please vote for: Launchpad Base 2.5.0 https://issues.apache.org/jira/browse/SLING/fixforversion/12321244 Scripting Console 1.0.0 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-3.0.9/ 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 3.0.9 /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 -- Felix Meschberger | Principal Scientist | Adobe
Re: [jira] [Created] (SLING-2762) AbstractSlingRepository#login violates JCR spec
Hi
Yes, we assume this under the backwards compatibility umbrella. IIRC
Jackrabbit supported the null-argument in this way, too. So we just made it
explicit.
What we might want to change, though, is to use JCR 2 GuestCredentials instead
of doing our own anonmous login stuff and thus get rid of the
PluggableLoginModule for anonnyous access.
we could also improve a bit by checking for an access control context:
if (credentials == null) {
if (hasAccessControlContext() hasSubject()) {
// assume external authentication
} else {
// assume backwards compatibility anon login
credentials = new GuestCredentials();
}
}
WDYT ?
Regards
Felix
Am 01.03.2013 um 10:43 schrieb Antonio Sanso (JIRA):
Antonio Sanso created SLING-2762:
Summary: AbstractSlingRepository#login violates JCR spec
Key: SLING-2762
URL: https://issues.apache.org/jira/browse/SLING-2762
Project: Sling
Issue Type: Bug
Components: JCR
Reporter: Antonio Sanso
AbstractSlingRepository#login seems to violate the javax.jcr.Repository spec.
The API [0] says
If credentials is null, it is assumed that authentication is handled by a
mechanism external to the repository itself (for example, through the JAAS
framework) and that the repository implementation exists within a context
(for example, an application server) that allows it to handle authorization
of the request for access to the specified workspace.
while the implementation looks like
{code}
...
if (credentials == null) {
credentials = getAnonCredentials(this.anonUser);
}
...
{code}
[0]
http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/Repository.html#login%28javax.jcr.Credentials,%20java.lang.String%29
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Felix Meschberger | Principal Scientist | Adobe
[jira] [Updated] (SLING-2763) Tweak PostServletCreateTest.testCreatingNodeUnderFile test to allow the presence of a PersistenceException
[
https://issues.apache.org/jira/browse/SLING-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated SLING-2763:
---
Issue Type: Improvement (was: Bug)
Tweak PostServletCreateTest.testCreatingNodeUnderFile test to allow the
presence of a PersistenceException
--
Key: SLING-2763
URL: https://issues.apache.org/jira/browse/SLING-2763
Project: Sling
Issue Type: Improvement
Components: Testing
Reporter: Alex Parvulescu
Priority: Minor
Running {{PostServletCreateTest.testCreatingNodeUnderFile}} against an Oak
repo, the test fails because it expects to see a
{{ConstraintViolationException}} on the page.
As oak has a different behavior wrt the moment when it throws the
{{ConstraintViolationException}}, it may end up being wrapped into a
{{PersistenceException}} which will fail the test even if the overall
expectations are met.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SLING-2763) Tweak PostServletCreateTest.testCreatingNodeUnderFile test to allow the presence of a PersistenceException
Alex Parvulescu created SLING-2763:
--
Summary: Tweak PostServletCreateTest.testCreatingNodeUnderFile
test to allow the presence of a PersistenceException
Key: SLING-2763
URL: https://issues.apache.org/jira/browse/SLING-2763
Project: Sling
Issue Type: Bug
Components: Testing
Reporter: Alex Parvulescu
Priority: Minor
Running {{PostServletCreateTest.testCreatingNodeUnderFile}} against an Oak
repo, the test fails because it expects to see a
{{ConstraintViolationException}} on the page.
As oak has a different behavior wrt the moment when it throws the
{{ConstraintViolationException}}, it may end up being wrapped into a
{{PersistenceException}} which will fail the test even if the overall
expectations are met.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2763) Tweak PostServletCreateTest.testCreatingNodeUnderFile test to allow the presence of a PersistenceException
[
https://issues.apache.org/jira/browse/SLING-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13590444#comment-13590444
]
Alex Parvulescu commented on SLING-2763:
For the interested parties here's how the test behaves in Jackrabbit vs Oak
*Jackrabbbit*
JR sees a pure {{ConstraintViolationException}}:
bq. javax.jcr.nodetype.ConstraintViolationException: No child node definition
for child found in node /CreateFileTest/1362039965324.txt
The code fails at {{AbstractPostOperation#run}} [0] at the {{#doRun}} call
which throws a {{RepositoryException}}.
The original {{ConstraintViolationException}} bubbles up unwrapped and ends up
in the page.
Stacktrace
javax.jcr.nodetype.ConstraintViolationException: No child node definition
for child found in node /CreateFileTest/1362074352827.txt
at org.apache.jackrabbit.core.NodeImpl.addNode(NodeImpl.java:1276)
at
org.apache.jackrabbit.core.session.AddNodeOperation.perform(AddNodeOperation.java:111)
at
org.apache.jackrabbit.core.session.AddNodeOperation.perform(AddNodeOperation.java:37)
at
org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
at org.apache.jackrabbit.core.NodeImpl.addNodeWithUuid(NodeImpl.java:1814)
at org.apache.jackrabbit.core.NodeImpl.addNode(NodeImpl.java:1774)
at
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.create(JcrResourceProvider.java:402)
at
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.create(ResourceResolverImpl.java:1063)
at
org.apache.sling.servlets.post.impl.operations.AbstractCreateOperation.deepGetOrCreateNode(AbstractCreateOperation.java:537)
at
org.apache.sling.servlets.post.impl.operations.AbstractCreateOperation.processCreate(AbstractCreateOperation.java:109)
at
org.apache.sling.servlets.post.impl.operations.ModifyOperation.doRun(ModifyOperation.java:91)
at
org.apache.sling.servlets.post.AbstractPostOperation.run(AbstractPostOperation.java:92)
*Oak*
Oak sees a {{PersistenceException}}:
bq. org.apache.sling.api.resource.PersistenceException: Unable to commit
changes to session.
The code fails at later phase in the {{AbstractPostOperation#run}} [1] at the
{{ResourceResolver().commit()}} call which effectively wraps the
{{ConstraintViolationException}} into a {{PersistenceException}} as per its
contract, which makes in into the page.
Stacktrace
org.apache.sling.api.resource.PersistenceException: Unable to commit changes
to session.
at
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.commit(JcrResourceProvider.java:461)
at
org.apache.sling.resourceresolver.impl.helper.ResourceResolverContext.commit(ResourceResolverContext.java:140)
at
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.commit(ResourceResolverImpl.java:1077)
at
org.apache.sling.servlets.post.AbstractPostOperation.run(AbstractPostOperation.java:129)
[0]
http://svn.apache.org/viewvc/sling/trunk/bundles/servlets/post/src/main/java/org/apache/sling/servlets/post/AbstractPostOperation.java?view=markup#l92
[0]
http://svn.apache.org/viewvc/sling/trunk/bundles/servlets/post/src/main/java/org/apache/sling/servlets/post/AbstractPostOperation.java?view=markup#l129
Tweak PostServletCreateTest.testCreatingNodeUnderFile test to allow the
presence of a PersistenceException
--
Key: SLING-2763
URL: https://issues.apache.org/jira/browse/SLING-2763
Project: Sling
Issue Type: Improvement
Components: Testing
Reporter: Alex Parvulescu
Priority: Minor
Running {{PostServletCreateTest.testCreatingNodeUnderFile}} against an Oak
repo, the test fails because it expects to see a
{{ConstraintViolationException}} on the page.
As oak has a different behavior wrt the moment when it throws the
{{ConstraintViolationException}}, it may end up being wrapped into a
{{PersistenceException}} which will fail the test even if the overall
expectations are met.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Monitoring and Statistics
On Fri, Mar 1, 2013 at 1:56 AM, Ian Boston i...@tfd.co.uk wrote: On 1 March 2013 20:17, Carsten Ziegeler cziege...@apache.org wrote: As outlined in the post that started this thread, using JMX from an implementation pov is pretty simple. To be honest extending StandardMBean is not the issue. Doing it in a way thats safe and low impact is, as you pointed out when talking about earlier attempts to generate stats. If each bundle has its own implementation we will re-invent the wheel... So maybe what's needed is a base/utility class that can be used in a very simple way to create MBeans that manage counters? Would this + a simple HTTP interface to read the counters cover your use cases? -Bertrand
[jira] [Created] (SLING-2764) Add server side support in sling to handle chunkupload
Shashank Gupta created SLING-2764: - Summary: Add server side support in sling to handle chunkupload Key: SLING-2764 URL: https://issues.apache.org/jira/browse/SLING-2764 Project: Sling Issue Type: Sub-task Reporter: Shashank Gupta -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SLING-2765) Add support to clean expired chunk uploads
Shashank Gupta created SLING-2765: - Summary: Add support to clean expired chunk uploads Key: SLING-2765 URL: https://issues.apache.org/jira/browse/SLING-2765 Project: Sling Issue Type: Sub-task Reporter: Shashank Gupta Have a scheduled job which cleans incomplete/expired chunk uploads: - have a configurable expiry time (e.g. 2 days) - run cleanup periodically as well (expiry time or 1/2 expiry time or ...) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SLING-2766) Provide client side javascript libraries to chunk upload feature
Shashank Gupta created SLING-2766: - Summary: Provide client side javascript libraries to chunk upload feature Key: SLING-2766 URL: https://issues.apache.org/jira/browse/SLING-2766 Project: Sling Issue Type: Sub-task Reporter: Shashank Gupta Provide client side javascript libraries to chunk upload feature -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2766) Provide client side javascript libraries to chunk upload feature
[ https://issues.apache.org/jira/browse/SLING-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13590517#comment-13590517 ] Alexander Klimetschek commented on SLING-2766: -- I guess some samples might be good, but otherwise Sling doesn't have to provide them. Important is proper documentation for the sling post servlet. http://sling.apache.org/site/manipulating-content-the-slingpostservlet-servletspost.html Provide client side javascript libraries to chunk upload feature Key: SLING-2766 URL: https://issues.apache.org/jira/browse/SLING-2766 Project: Sling Issue Type: Sub-task Components: General Reporter: Shashank Gupta Provide client side javascript libraries to chunk upload feature -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: sling pull request: SLING-2707 Support of chunked file upload into Sling
On 01.03.2013, at 09:41, Felix Meschberger fmesc...@adobe.com wrote: I have the impression, I prefer patches attached to the respective Sling issue for better recording. Agree, based on existing practice, but I am not a committer to make such a decision. Cheers, Alex
[jira] [Commented] (SLING-2762) AbstractSlingRepository#login violates JCR spec
[
https://issues.apache.org/jira/browse/SLING-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13590525#comment-13590525
]
angela commented on SLING-2762:
---
apart from violating the spec this also pretty awkward as the 'anonymous' in
sling represents the unauthenticated user.
login as such with other credentials that javax.jcr.GuestCredentials doesn't
make sense IMHO.
it's actually an oddity (or bug) in jackrabbit core that it was (actually is)
possible to login with SimpleCredentials build for the
anonymous user that has not been fixed in order not to break backwards
compatibility.
as of oak that special handling for the anonymous user will not be supported
any more and the built-in anonymous user
will not have a password property any more... so login(new
SimpleCredentials(anonymous, ) will no longer work.
instead login(new GuestCredentials) will succeed if a valid anonymous user
exists.
similarly, login(null) will no longer be converted into an anonymous-login by
default. to ease migration and provide a
backwards compatible setup there exists a separate loginmodule implementation
that will populate the shared-state
with guestcredentials in case of null-login.
hope that helps
AbstractSlingRepository#login violates JCR spec
---
Key: SLING-2762
URL: https://issues.apache.org/jira/browse/SLING-2762
Project: Sling
Issue Type: Bug
Components: JCR
Reporter: Antonio Sanso
AbstractSlingRepository#login seems to violate the javax.jcr.Repository spec.
The API [0] says
If credentials is null, it is assumed that authentication is handled by a
mechanism external to the repository itself (for example, through the JAAS
framework) and that the repository implementation exists within a context
(for example, an application server) that allows it to handle authorization
of the request for access to the specified workspace.
while the implementation looks like
{code}
...
if (credentials == null) {
credentials = getAnonCredentials(this.anonUser);
}
...
{code}
[0]
http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/Repository.html#login%28javax.jcr.Credentials,%20java.lang.String%29
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: sling pull request: SLING-2707 Support of chunked file upload into Sling
Hi On Fri, Mar 1, 2013 at 3:41 AM, Felix Meschberger fmesc...@adobe.comwrote: Hi Thanks for the pull request. I have the impression, I prefer patches attached to the respective Sling issue for better recording. I personally am fine in general with getting pull requests. You can always get the .patch file by appending .patch to the URL, e.g. https://github.com/apache/sling/pull/1.patch The pull request should be linked to from the JIRA issue. In this case, it looks like there are some issues with the patch. Whether discussion of the patch happens in github, Rietveld, or Review Board (which I've never been able to successfully post to) should be IMHO up to the patch submitter. Justin WDOT ? Regards Felix Am 28.02.2013 um 17:02 schrieb shashank-itbhu: GitHub user shashank-itbhu opened a pull request: https://github.com/apache/sling/pull/1 SLING-2707 Support of chunked file upload into Sling Feature enhance with details at https://cwiki.apache.org/confluence/display/SLING/Chunked+File+Upload+Support 1. Extension to [SlingPostServlet| http://sling.apache.org/site/manipulating-content-the-slingpostservlet-servletspost.html ] 2. Chunk upload is supported in modifyoperation of [SlingPostServlet| http://sling.apache.org/site/manipulating-content-the-slingpostservlet-servletspost.html] ( ie. In default operation) . No new operation introduced for it 3. Chunks are saved in temporary location identified by upload id 4. Chunk processing * First/Intermediate chunks: Chunk is saved in temporary location in jcr. Ignores all upload semantics (@TypeHint, etc) and request parameters. * Last chunk: Stitches all chunks. Process all upload semantics and request parameters and creates jcr node structure at the right location. You can merge this pull request into a Git repository by running: $ git pull https://github.com/shashank-itbhu/sling trunk Alternatively you can review and apply these changes as the patch at: https://github.com/apache/sling/pull/1.patch commit 1a3b17d498bf8781dab7ffcfffce3335e00dad72 Author: Shashank Gupta shgu...@adobe.com Date: 2013-02-28T15:59:42Z SLING-2707 Support of chunked file upload into Sling Feature enhance with details at https://cwiki.apache.org/confluence/display/SLING/Chunked+File+Upload+Support 1. Extension to [SlingPostServlet| http://sling.apache.org/site/manipulating-content-the-slingpostservlet-servletspost.html ] 2. Chunk upload is supported in modifyoperation of [SlingPostServlet| http://sling.apache.org/site/manipulating-content-the-slingpostservlet-servletspost.html] ( ie. In default operation) . No new operation introduced for it 3. Chunks are saved in temporary location identified by upload id 4. Chunk processing * First/Intermediate chunks: Chunk is saved in temporary location in jcr. Ignores all upload semantics (@TypeHint, etc) and request parameters. * Last chunk: Stitches all chunks. Process all upload semantics and request parameters and creates jcr node structure at the right location. -- Felix Meschberger | Principal Scientist | Adobe
[jira] [Issue Comment Deleted] (SLING-2760) org.apache.sling.auth.openid bundle has dependencies not available on Maven central
[
https://issues.apache.org/jira/browse/SLING-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson updated SLING-2760:
--
Comment: was deleted
(was: Dear sender,
I am out of office until the 4th of March with limited access to email. I will
reply to your email once I return.
Regards,
Robert Munteanu
)
org.apache.sling.auth.openid bundle has dependencies not available on Maven
central
---
Key: SLING-2760
URL: https://issues.apache.org/jira/browse/SLING-2760
Project: Sling
Issue Type: Bug
Components: Authentication
Affects Versions: OpenID Authentication 1.0.2
Reporter: Robert Munteanu
Priority: Minor
The org.apache.sling.auth.openid bundle includes the following repository
definition in its pom.xml file
{code}repositories
repository
releases
enabledtrue/enabled
/releases
iddyuproject-repo/id
namedyuproject-repo/name
urlhttp://dyuproject.googlecode.com/svn/repos/maven2/url
/repository
/repositories
{code}
and the following dependencies
{code}
dependency
groupIdcom.dyuproject/groupId
artifactIddyuproject-openid/artifactId
version1.1.7/version
/dependency
dependency
groupIdcom.dyuproject/groupId
artifactIddyuproject-util/artifactId
version1.1.7/version
/dependency
dependency
groupIdcom.dyuproject/groupId
artifactIddyuproject-json/artifactId
version1.1.7/version
/dependency
{code}
Since we sync/upload these artifacts to maven central [1] we should consider
following the recommendation of not adding repositories to POMs [2] . There
is an open request in the dyuproject tracker [3] to upload the openid
artifacts to Maven Central, but it's been there for almost two years, and the
project hasn't seen much activity ( no commits since June 2011 ).
I see two ways around this issue:
- Use the sonatype service for uploading 3rd party bundles to Maven Central
[4]
- Replace the com.dyuproject dependency with something different
Thoughts?
[1]: http://search.maven.org/#search|ga|1|org.apache.sling.auth.openid
[2]:
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-6.CentralSyncRequirement
[3]: http://code.google.com/p/dyuproject/issues/detail?id=32
[4]:
https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+The+Central+Repository
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Monitoring and Statistics
Hi,
On Mar 1, 2013, at 4:56 AM, Ian Boston i...@tfd.co.uk wrote:
On 1 March 2013 20:17, Carsten Ziegeler cziege...@apache.org wrote:
Hi,
I agree with Felix here - we should have a coherent story here and JMX
looks like a good solution to me as well. As outlined in the post that
started this thread, using JMX from an implementation pov is pretty
simple.
To be honest extending StandardMBean is not the issue. Doing it in a
way thats safe and low impact is, as you pointed out when talking
about earlier attempts to generate stats. If each bundle has its own
implementation we will re-invent the wheel, and getting even simple
counters right with no synchronisation is not as simple as volatile
int x; i++; Its not hard by has to be done in the right way.
So are there any concerns or problems for using JMX from a client pov?
Depends on who you talk to.
Most sysops people dont like JMX due to the cost of querying it and
most java devs do like it because it has GUI tools. Most sysops tools
have bridges that spin up a JVM, query JMX and convert the stats into
some other format, (Resmon XML, RRDTool). That uses a minimum of 64MB
of RAM and sysops people tend to get a bit agitated by that when they
compare it to what a python/bash/c command uses.
No REST interface is not really an issue and I guess it would be easy
to write a JMX over REST bridge :)
It would and it could live in a separate optional bundle for anyone
that wanted it and I could write a JMX Bean ontop of the map as I did
for the Jackrabbit RepositoryStatistics
I really like Jolokia (http://www.jolokia.org/) as a JMX/HTTP bridge. It comes
out of jmx4perl and is ASLv2 licensed. They already provide an OSGi bundle
which can just be dropped in and works. I started to write a Sling-specific
bundlization which would use repository credentials rather than user/password
hard coded in a configuration file (similar to the WebConsole).
Unless there's some specific defect, let's just use this.
Justin
Best Regards
Ian
Regards
Carsten
2013/3/1 Felix Meschberger fmesc...@adobe.com:
Hi
I really appreciate this discussion. But I would like to get to a point
where we create a proper future-proof (as much as possible) architecture
which properly integrates with the current situation:
* JMX is the system of choice for systems management
* The Web Console is the respective system of choice
for web based interactive tooling
* Don't reinvent wheels
I would really like to highlight the last point: I would prefer to reuse
existing functionality and libraries as much as possible instead of
reinventing our own stuff using yet another channel.
Regards
Felix
Am 22.02.2013 um 23:59 schrieb Ian Boston:
Hi,
Whilst writing the MBeans in the event bundle I started thinking about
monitoring inside Sling. IMHO there are not enough to really know what
a instance under load is doing. Much though I like JMX it comes with
implementation and runtime overhead which I don't much like.
Runtime:
* Running with JMX enabled doesn't add any overhead, but once a client
is connected there is some (some reports upto 3% of resources).
* You have to remember to enable it, and most of the time JVMs are not
enabled. By the time you really need it, its often too late.
* JMX is not restful.
Implementation
* MBeans are not that hard to implement with the OSGi Whiteboard, but
they have to be implemented.
Alternatives.
In Jackarabbit there is/was a statistics class [1], which IIUC uses
counters and time series stored in a map. The service can then be
queries to extract the values by wrapping in an MBean or Servlet.
I think the approach could be generalised and extended so that
anything in the container could use the service to record metrics. The
api might look something like
public interface Statistics {
/**
* Increment a counter by 1
*/
void increment(String counterName);
/**
* Record a double value in a timeseries.
*/
void record(String timeSeriesName, double value);
/**
* Record a long value in a timeseries.
*/
void record(String timeSeriesName, long value);
}
and (so that any reference can be optional on a service
implementation, the final is a hint to hotspot to inline)
public final class StatisticsUtils {
private StatisticsUtils() {
}
public static void increment(Statistics statistics, String counterName) {
if ( statistics != null ) {
statistics.increment(counterName);
}
}
... etc for the other methods ..
}
The service would need to deal with all the implementation details
(including concurrency and speed). The service implementation would
also come with a servlet endpoint (under /system/*) and/or single JMX
MBean.
Anything that wanted to record stats would then bind to the service
and use it. I think this would avoid the issues mentioned above with
wide
[jira] [Commented] (SLING-2762) AbstractSlingRepository#login violates JCR spec
[
https://issues.apache.org/jira/browse/SLING-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13590609#comment-13590609
]
Felix Meschberger commented on SLING-2762:
--
GuestCredentials
Remember this Sling implementations dates back to JCR 1 where there was no
GuestCredentials and we never adapted this code.
login(null) support
Thanks for the update. For Sling which wraps its own Repository wrapper around
the actual Repository we can still implement the support.
As I tried to bring the discussion to the list, I propose replace the
respective code with something similar to this:
if (credentials == null) {
if (!hasAccessControlContext || !hasSubject) {
credentials = new GuestCredentials();
}
}
This allows for backwards compatibility (where generally there will be no
AccessControlContext with a Subject) while at the same time allow for Subject
based authentication.
AbstractSlingRepository#login violates JCR spec
---
Key: SLING-2762
URL: https://issues.apache.org/jira/browse/SLING-2762
Project: Sling
Issue Type: Bug
Components: JCR
Reporter: Antonio Sanso
AbstractSlingRepository#login seems to violate the javax.jcr.Repository spec.
The API [0] says
If credentials is null, it is assumed that authentication is handled by a
mechanism external to the repository itself (for example, through the JAAS
framework) and that the repository implementation exists within a context
(for example, an application server) that allows it to handle authorization
of the request for access to the specified workspace.
while the implementation looks like
{code}
...
if (credentials == null) {
credentials = getAnonCredentials(this.anonUser);
}
...
{code}
[0]
http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/Repository.html#login%28javax.jcr.Credentials,%20java.lang.String%29
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SLING-2767) Typos in documentation eventing-and-jobs.html
Lukas Eder created SLING-2767: - Summary: Typos in documentation eventing-and-jobs.html Key: SLING-2767 URL: https://issues.apache.org/jira/browse/SLING-2767 Project: Sling Issue Type: Bug Components: Documentation Reporter: Lukas Eder Priority: Trivial There are two trivial typos on the eventing-and-jobs.html page for the Sling documentation. I will attach a patch to fix them -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-2767) Typos in documentation eventing-and-jobs.html
[ https://issues.apache.org/jira/browse/SLING-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Eder updated SLING-2767: -- Attachment: eventing-and-jobs.html.patch Patch fixing the typos Typos in documentation eventing-and-jobs.html - Key: SLING-2767 URL: https://issues.apache.org/jira/browse/SLING-2767 Project: Sling Issue Type: Bug Components: Documentation Reporter: Lukas Eder Priority: Trivial Attachments: eventing-and-jobs.html.patch There are two trivial typos on the eventing-and-jobs.html page for the Sling documentation. I will attach a patch to fix them -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (SLING-2670) Add support for suffix addressed resources
[
https://issues.apache.org/jira/browse/SLING-2670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler reassigned SLING-2670:
---
Assignee: Carsten Ziegeler
Add support for suffix addressed resources
--
Key: SLING-2670
URL: https://issues.apache.org/jira/browse/SLING-2670
Project: Sling
Issue Type: Improvement
Components: API, Engine
Affects Versions: Engine 2.2.6, API 2.3.0
Reporter: Tobias Bocanegra
Assignee: Carsten Ziegeler
Priority: Minor
Fix For: Engine 2.2.8, API 2.3.2
Attachments: SLING-2670-complete.patch, SLING-2670.patch
For web applications like user consoles or administration panels, it's common
to store the layout information in the content (resource). This content can
then be addressed naturally and the respective scripts then used to render
the GUI of the console. When the console need to display information of
existing resources, their path needs to be passed in the URL as well. one
option is a query parameter, another the request suffix.
eg:
http://localhost:8080/content/webconsole/grid.html/content/products
Every script or servlet needs to transform the suffix into a resource with
something like:
Resource targetResource =
request.getResourceResolver().getResource(request.getRequestPathInfo().getSuffix());
which is a bit repetitive, error prone and not cached.
therefor I sugest to introduce:
org.apache.sling.api.request.RequestPathInfo {
/**
* Returns the resource addressed by the suffix or null if the resource
does not exist. The suffix is
* considered to address the resource directly as path.
*/
Resource getSuffixResource();
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SLING-2670) Add support for suffix addressed resources
[
https://issues.apache.org/jira/browse/SLING-2670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved SLING-2670.
-
Resolution: Fixed
I've applied to patch
Add support for suffix addressed resources
--
Key: SLING-2670
URL: https://issues.apache.org/jira/browse/SLING-2670
Project: Sling
Issue Type: Improvement
Components: API, Engine
Affects Versions: Engine 2.2.6, API 2.3.0
Reporter: Tobias Bocanegra
Assignee: Carsten Ziegeler
Priority: Minor
Fix For: Engine 2.2.8, API 2.3.2
Attachments: SLING-2670-complete.patch, SLING-2670.patch
For web applications like user consoles or administration panels, it's common
to store the layout information in the content (resource). This content can
then be addressed naturally and the respective scripts then used to render
the GUI of the console. When the console need to display information of
existing resources, their path needs to be passed in the URL as well. one
option is a query parameter, another the request suffix.
eg:
http://localhost:8080/content/webconsole/grid.html/content/products
Every script or servlet needs to transform the suffix into a resource with
something like:
Resource targetResource =
request.getResourceResolver().getResource(request.getRequestPathInfo().getSuffix());
which is a bit repetitive, error prone and not cached.
therefor I sugest to introduce:
org.apache.sling.api.request.RequestPathInfo {
/**
* Returns the resource addressed by the suffix or null if the resource
does not exist. The suffix is
* considered to address the resource directly as path.
*/
Resource getSuffixResource();
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[RT] ResourceMetadata
Hi, while looking into some issues, I realized that ResourceMetadata is not only extending a HashMap (which makes handling easier), but we have absolutely no information if this map can be changed by client code or is a read-only map. I think we should add this to the documentation and make this read-only. We could either just document it or add a make read-only method to ResourceMetadata which is called by the resource resolver before the resource object is returned to the client code. But I think we should not allow client code to change/add/remove to ResourceMetadata. WDYT Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [jira] [Created] (SLING-2762) AbstractSlingRepository#login violates JCR spec
hi felix
that makes sense. in general i would suggest to consistently use
GuestCredentials and get rid of the jr-core-null workaround that
in fact relies on an comfortable but somewhat incorrect
implementation detail...
hope that helps
angela
On 3/1/13 11:29 AM, Felix Meschberger wrote:
Hi
Yes, we assume this under the backwards compatibility umbrella. IIRC
Jackrabbit supported the null-argument in this way, too. So we just made it explicit.
What we might want to change, though, is to use JCR 2 GuestCredentials instead
of doing our own anonmous login stuff and thus get rid of the
PluggableLoginModule for anonnyous access.
we could also improve a bit by checking for an access control context:
if (credentials == null) {
if (hasAccessControlContext() hasSubject()) {
// assume external authentication
} else {
// assume backwards compatibility anon login
credentials = new GuestCredentials();
}
}
WDYT ?
Regards
Felix
Am 01.03.2013 um 10:43 schrieb Antonio Sanso (JIRA):
Antonio Sanso created SLING-2762:
Summary: AbstractSlingRepository#login violates JCR spec
Key: SLING-2762
URL: https://issues.apache.org/jira/browse/SLING-2762
Project: Sling
Issue Type: Bug
Components: JCR
Reporter: Antonio Sanso
AbstractSlingRepository#login seems to violate the javax.jcr.Repository spec.
The API [0] says
If credentials is null, it is assumed that authentication is handled by a
mechanism external to the repository itself (for example, through the JAAS framework) and
that the repository implementation exists within a context (for example, an application
server) that allows it to handle authorization of the request for access to the specified
workspace.
while the implementation looks like
{code}
...
if (credentials == null) {
credentials = getAnonCredentials(this.anonUser);
}
...
{code}
[0]
http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/Repository.html#login%28javax.jcr.Credentials,%20java.lang.String%29
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Felix Meschberger | Principal Scientist | Adobe
Re: Status of the OCM Bundle?
+1 for contrib On Feb 25, 2013, at 9:49 AM, Felix Meschberger fmesc...@adobe.com wrote: +1 to moving to contrib IMHO it nicely shows the functionality of the Resource API and the Adaptable pattern and it still serves as an example if people insist on OCM. So moving to the attic is not a good idea, IMHO. Maybe move to samples ? ;-) Regards Felix Am 22.02.2013 um 17:15 schrieb Carsten Ziegeler: Hi, while looking at our open issues, I noticed we have some open for OCM and that made me thought about this bundle :) I think it hasn't been maintained for years and isn't really used, so what about a) moving it to the contrib section - so it's still around but not one of our main bundles anymore b) move it to the attic WDYT? Carsten -- Carsten Ziegeler cziege...@apache.org -- Felix Meschberger | Principal Scientist | Adobe
Re: Monitoring and Statistics
On 2 March 2013 01:45, Justin Edelson jus...@justinedelson.com wrote: No REST interface is not really an issue and I guess it would be easy to write a JMX over REST bridge :) It would and it could live in a separate optional bundle for anyone that wanted it and I could write a JMX Bean ontop of the map as I did for the Jackrabbit RepositoryStatistics I really like Jolokia (http://www.jolokia.org/) as a JMX/HTTP bridge. It comes out of jmx4perl and is ASLv2 licensed. They already provide an OSGi bundle which can just be dropped in and works. I started to write a Sling-specific bundlization which would use repository credentials rather than user/password hard coded in a configuration file (similar to the WebConsole). Unless there's some specific defect, let's just use this. Hi, I am +1 with the following observations: The project documentation gives a good introduction and documents the reasons why JMX remote is problematic. The chapter on architecture [1] gives a detailed description and the section on the HTTP-JMX proxy explains all the problems associated with JSR-160 and RMI in the wild. There are one or two problems with the protocol, that I think are significant and we might want to think about. 1. GETs modifiy data. The protocol allows a GET operation to invoke a JMX operation, modifying state. 2. GETs can only query 1 bean at a time. If you need a snapshot of the state of the server and have 50 MBeans, you have to make 50 requests. You can make POST requests to perform batch up GET requests. Fortunately you can specify a * for attributes. 3. POSTs allow invoking operations. The bridge gives full access to all JMX operations. It might be possible to disable 1 and 3 using access control policies that are available within Jolokia, however I think this might have to be done on a bean by bean basis which would but section 4 of the manual [2] appears to indicate that wildcards on bean names can be used. I dont see a way around 2 other than to use POST operations as GETs, although it might be possible to re-implement the GET operation to expose a OSGi configured set of statistics in a single GET operation. Best Regards Ian 1 http://www.jolokia.org/reference/html/architecture.html 2 http://www.jolokia.org/reference/html/security.html Justin Best Regards Ian
Re: Monitoring and Statistics
On 2 March 2013 10:42, Ian Boston i...@tfd.co.uk wrote: 2. GETs can only query 1 bean at a time. If you need a snapshot of the state of the server and have 50 MBeans, you have to make 50 requests. You can make POST requests to perform batch up GET requests. Fortunately you can specify a * for attributes. Correction: A SlingServlet extending the AgentServlet form Jolokia registered at /system/stats triggers authentication and can be restricted to GET only with the SlingServlet annotation. Provided the query is performed in a parameter [1], its possible to retrieve all MBeans, however, Jolokia ignores the Attributes that it doesn't understand how to convert into json. For instance, the TimeSeries in Jackrabbit is ignored. I think any container that isn't a primitive or open type is ignored even if it contains data that could be output. I am not really certain of the value of this work any more, so I am not going to do anything further, unless there is a strong demand. Best Regards Ian 1 http://localhost:4502/system/stats?p=read/*:type=*
