RE: extending jQuery JCR Resource explorer
> A nice thing would be to use the Sling script resolution to plugin > custom content editors based on resource types. sounds interesting > -Original Message- > From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] > Sent: Friday, August 13, 2010 6:22 PM > To: dev@sling.apache.org > Subject: Re: extending jQuery JCR Resource explorer > > > On Thu, Aug 12, 2010 at 4:26 PM, Clemens Wyss > wrote: > > ...Anything important/fancy missing? How would you priorize > these features?.. > > A nice thing would be to use the Sling script resolution to plugin > custom content editors based on resource types. > > Maybe just use .explorer.edit selectors to generate a composite UI > where users can plugin their own editing components, and define a > simple set of guidelines/constraints that those components must > follow. > > -Bertrand >
RE: extending jQuery JCR Resource explorer
I had a first look at your explorer. If I get this right: + new, more appealing, GUI + new js-tree + properties are no more being edited inline, which makes sense + privileges, minimal did I miss a "hidden feature"? > -Original Message- > From: Clemens Wyss [mailto:clemens...@mysign.ch] > Sent: Saturday, August 14, 2010 7:20 AM > To: 'dev@sling.apache.org' > Subject: RE: extending jQuery JCR Resource explorer > > > Hi Mike, > cool. If you don't mind, I will take "your" code base and > build upon this > > Thx > Clemens > > > -Original Message- > > From: Mike Moulton [mailto:m...@meltmedia.com] > > Sent: Saturday, August 14, 2010 12:00 AM > > To: dev@sling.apache.org > > Subject: Re: extending jQuery JCR Resource explorer > > > > > > I'm a little late to this thread but I wanted to bring this > > up anyway. A while back when I first was learning Sling I > > created an extended explorer based on the original version in > > the contrib. section. My explorer uses jQuery and > > accomplished most of the items of the current jQuery > > explorer. Before an extended set of work started on > > enhancements I wanted to donate this codebase in case it's of > > any use in this effort. I would love to see a mature explorer > > ship as a part of Sling, and any work I can do to help that, > > I will do. > > > > I created SLING-1653 [1] with the codebase in it. > > > > [1] https://issues.apache.org/jira/browse/SLING-1653 > > > > > > On Aug 13, 2010, at 9:21 AM, Bertrand Delacretaz wrote: > > > > > On Thu, Aug 12, 2010 at 4:26 PM, Clemens Wyss > > wrote: > > >> ...Anything important/fancy missing? How would you > > priorize these features?.. > > > > > > A nice thing would be to use the Sling script resolution to plugin > > > custom content editors based on resource types. > > > > > > Maybe just use .explorer.edit selectors to generate a composite UI > > > where users can plugin their own editing components, and define a > > > simple set of guidelines/constraints that those components must > > > follow. > > > > > > -Bertrand > > > > >
RE: extending jQuery JCR Resource explorer
Hi Mike, cool. If you don't mind, I will take "your" code base and build upon this Thx Clemens > -Original Message- > From: Mike Moulton [mailto:m...@meltmedia.com] > Sent: Saturday, August 14, 2010 12:00 AM > To: dev@sling.apache.org > Subject: Re: extending jQuery JCR Resource explorer > > > I'm a little late to this thread but I wanted to bring this > up anyway. A while back when I first was learning Sling I > created an extended explorer based on the original version in > the contrib. section. My explorer uses jQuery and > accomplished most of the items of the current jQuery > explorer. Before an extended set of work started on > enhancements I wanted to donate this codebase in case it's of > any use in this effort. I would love to see a mature explorer > ship as a part of Sling, and any work I can do to help that, > I will do. > > I created SLING-1653 [1] with the codebase in it. > > [1] https://issues.apache.org/jira/browse/SLING-1653 > > > On Aug 13, 2010, at 9:21 AM, Bertrand Delacretaz wrote: > > > On Thu, Aug 12, 2010 at 4:26 PM, Clemens Wyss > wrote: > >> ...Anything important/fancy missing? How would you > priorize these features?.. > > > > A nice thing would be to use the Sling script resolution to plugin > > custom content editors based on resource types. > > > > Maybe just use .explorer.edit selectors to generate a composite UI > > where users can plugin their own editing components, and define a > > simple set of guidelines/constraints that those components must > > follow. > > > > -Bertrand > >
Re: extending jQuery JCR Resource explorer
I'm a little late to this thread but I wanted to bring this up anyway. A while back when I first was learning Sling I created an extended explorer based on the original version in the contrib. section. My explorer uses jQuery and accomplished most of the items of the current jQuery explorer. Before an extended set of work started on enhancements I wanted to donate this codebase in case it's of any use in this effort. I would love to see a mature explorer ship as a part of Sling, and any work I can do to help that, I will do. I created SLING-1653 [1] with the codebase in it. [1] https://issues.apache.org/jira/browse/SLING-1653 On Aug 13, 2010, at 9:21 AM, Bertrand Delacretaz wrote: > On Thu, Aug 12, 2010 at 4:26 PM, Clemens Wyss wrote: >> ...Anything important/fancy missing? How would you priorize these features?.. > > A nice thing would be to use the Sling script resolution to plugin > custom content editors based on resource types. > > Maybe just use .explorer.edit selectors to generate a composite UI > where users can plugin their own editing components, and define a > simple set of guidelines/constraints that those components must > follow. > > -Bertrand
[jira] Created: (SLING-1653) Donation of enhanced explorer
Donation of enhanced explorer - Key: SLING-1653 URL: https://issues.apache.org/jira/browse/SLING-1653 Project: Sling Issue Type: Improvement Reporter: Mike Moulton I was reading the recent thread [1] about extending the current explorer stubs available in the contrib. section. A while back when I was first learning Sling I extended what was the existing explorer at the time to teach myself the inner workings of Sling. The project was never complete, however a decent amount of work was done to produce a complete explorer. Given the conversation and the renewed interest in development, I wanted to offer up my explorer to Sling. I'm not sure if this version is a better starting point to accomplish Clemens goals, but if so, you are welcome to build off it. Most of the code is my own, however their are some third party libraries that are used. It looks like they all have ASF friendly licensing, however this is obviously something that will need to be investigated. To use this explorer you can build the bundle, then install it. The explorer will then be available at .explorer.html e.g., http://localhost:8080/.explorer.html [1] http://apache-sling.73963.n3.nabble.com/VOTE-Grant-Jean-Christophe-write-access-to-the-docs-was-Re-Scheduler-service-problem-tp1028822p405.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1653) Donation of enhanced explorer
[ https://issues.apache.org/jira/browse/SLING-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Moulton updated SLING-1653: Attachment: sling-explorer.tar.gz > Donation of enhanced explorer > - > > Key: SLING-1653 > URL: https://issues.apache.org/jira/browse/SLING-1653 > Project: Sling > Issue Type: Improvement >Reporter: Mike Moulton > Attachments: sling-explorer.tar.gz > > > I was reading the recent thread [1] about extending the current explorer > stubs available in the contrib. section. A while back when I was first > learning Sling I extended what was the existing explorer at the time to teach > myself the inner workings of Sling. The project was never complete, however a > decent amount of work was done to produce a complete explorer. Given the > conversation and the renewed interest in development, I wanted to offer up my > explorer to Sling. I'm not sure if this version is a better starting point to > accomplish Clemens goals, but if so, you are welcome to build off it. Most of > the code is my own, however their are some third party libraries that are > used. It looks like they all have ASF friendly licensing, however this is > obviously something that will need to be investigated. > To use this explorer you can build the bundle, then install it. The explorer > will then be available at .explorer.html e.g., > http://localhost:8080/.explorer.html > [1] > http://apache-sling.73963.n3.nabble.com/VOTE-Grant-Jean-Christophe-write-access-to-the-docs-was-Re-Scheduler-service-problem-tp1028822p405.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: where is the esp-syntax described?
ESP is Embedded ECMAScript (Javascript). Inside <% and %> you can use any ECMAScript statement you want, including if, else if, switch and case. Lars On Fri, Aug 13, 2010 at 11:59 AM, Clemens Wyss wrote: > e.g. is there an "else if" or "elsif"? How about a switch/case? > Thx > -- Lars Trieloff - http://lars.mp - Day Software - http://www.day.com
where is the esp-syntax described?
e.g. is there an "else if" or "elsif"? How about a switch/case? Thx
[jira] Updated: (SLING-1438) GSoC 2010: create a mini-CMS to demonstrate Sling
[ https://issues.apache.org/jira/browse/SLING-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Federico Paparoni updated SLING-1438: - Attachment: david.rar Submit of "David Mini CMS". > GSoC 2010: create a mini-CMS to demonstrate Sling > - > > Key: SLING-1438 > URL: https://issues.apache.org/jira/browse/SLING-1438 > Project: Sling > Issue Type: Task > Components: Documentation >Reporter: Bertrand Delacretaz >Assignee: Federico Paparoni > Attachments: david.rar > > > This is a suggested project for Google Summer of Code 2010. > The goal is to create a mini-CMS with Sling, that demonstrates Sling best > practices. > The emphasis is on the quality and readability of the demo code, and we > expect to have to go through several iterations to refine it and the > corresponding JCR content model so that they demonstrate Sling best > practices. We will not necessarily create a full-fledged CMS, the goal is for > the result to be educational and help Sling newcomers understand how to > create web applications with it. > Suggested technologies: jQuery for the front-end, ESP and/or JSP for > server-side scripting, and Java code in OSGi bundles for back-end > functionality. > See http://tinyurl.com/asfgsoc for the full list of GSoC 2010 projects at the > ASF, and http://community.apache.org/gsoc for general GSoC information. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: extending jQuery JCR Resource explorer
On Thu, Aug 12, 2010 at 4:26 PM, Clemens Wyss wrote: > ...Anything important/fancy missing? How would you priorize these features?.. A nice thing would be to use the Sling script resolution to plugin custom content editors based on resource types. Maybe just use .explorer.edit selectors to generate a composite UI where users can plugin their own editing components, and define a simple set of guidelines/constraints that those components must follow. -Bertrand
[jira] Commented: (SLING-1631) Classloading problems when taglibs are used.
[ https://issues.apache.org/jira/browse/SLING-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898291#action_12898291 ] Carsten Ziegeler commented on SLING-1631: - Another update to taglib loading: it now uses the same mechanism to detect if a dirty class loader is uses as is done for servlets. This removes the need to restart the jsp scripting for taglib changes - this is already done by the class loading. > Classloading problems when taglibs are used. > > > Key: SLING-1631 > URL: https://issues.apache.org/jira/browse/SLING-1631 > Project: Sling > Issue Type: Bug > Components: Scripting >Affects Versions: Scripting JSP 2.0.8 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Scripting JSP 2.0.10 > > > When taglibs are used together with jsp scripting there are several problems: > 1. The taglib cache does not detect changes to taglibs (contained in bundles) > like the general classloading mechanism through the dynamic classloader - > this can result in inconsistencies and classloading problems. > 2. The last modified check for taglibs does not work as expected. As soon as > tags are used, they are considered as changed which results in recompilation > of the jsp and of the tag where the second invalidates the classloader of the > jsp. This classloader is later on used and then a classloading exception is > thrown -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Sling 6] Closing out remaining JCR features
So it looks like we should be able to start releasing the JCR bundles very soon after next week's API release. Good times! I would like to upgrade to JR 2.1.1, but that looks trivial to do. I can do some similar JIRA analysis next week on the other bundles. But I think API, Auth, and JCR are the big ones. Maybe we can get Sling 6 out before JavaOne... On Aug 13, 2010, at 2:59 AM, Felix Meschberger wrote: > Hi, > > Sorry, to have this missed for far too long > > On 14.07.2010 02:26, Justin Edelson wrote: >> Following onto my email from last week regarding the outstanding issues >> for the API 2.1.0 release, I wanted to send a similar email about the >> various JCR related bundles. Here the story is more complex and I think >> we need to push some of these issues into a later release. >> >> Issues which appear to resolved: >> SLING-1566 - adding ResourceResolver.isLive() - as I mentioned, this >> looks like it can be marked as Resolved (Felix?) > > Done, some time ago. > >> SLING-1132 - wrong bundle version > > I have fixed this and closed the issue. > >> >> Doc Required: >> SLING-1519 - URL mapping for paths containing "-" > > Yes, but IMHO not a release blocker > >> >> Issues for which patches are available: >> SLING-1548 - move bundle event handling to Loader > > Yes, is on my plate to finally complete this > >> SLING-1463 - use OSGi events instead of JCR events for MapEntries > > nice to have ?? > >> SLING-1198 - Allow mapping nodes to internet domains with template >> parameters > > IMO this probably requires more more and extensions to be done. So I > propose to postpone this to after the release. > >> >> Issues I think we can move out of the next release cycle: >> SLING-1455 - Impossible to refer to same-name-siblings when doing >> internal redirect to another protocol > > Added a comment. If we can come up with a good solution quickly, we > could get it solved in time... Not sure. > >> SLING-1421 - Resorce Resolver Mapping - Better Support for Multiple >> Domain/Protocol Mapping > > Agreed, postpone. > >> SLING-1391 - Make JcrModifiablePropertyMap write changes directly > > This is a disputed issue ;-) Implementation looks simple, though. > >> SLING-1332 - Support multi-value sling:alias resolution > > This was a small one, thus I quickly fixed it. > >> >> here's the JIRA query: >> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310710&fixfor=12314772&fixfor=12314758&fixfor=12314415&fixfor=12314472&fixfor=12314286&fixfor=12314773&fixfor=12314769&fixfor=12314442&fixfor=12314774&fixfor=12313431&fixfor=12314768&fixfor=12314564&resolution=-1&sorter/field=issuekey&sorter/order=DESC > > There are few recent issues I am about to close. > > Regards > Felix > >> >> Also worth looking at is this query: >> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310710&component=12311946&fixfor=-1&resolution=-1&sorter/field=issuekey&sorter/order=DESC >> >> This is the issues marked with the JCR component but no Fix Version. >> >> Justin >>
[jira] Commented: (SLING-1560) Improve and clean up code
[ https://issues.apache.org/jira/browse/SLING-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898288#action_12898288 ] Carsten Ziegeler commented on SLING-1560: - Changes in revision 985253 Separate support for bundles and configs - put each one in own packae Removed the EventSupport and updated to latest Sling testing > Improve and clean up code > - > > Key: SLING-1560 > URL: https://issues.apache.org/jira/browse/SLING-1560 > Project: Sling > Issue Type: Improvement > Components: Installer >Affects Versions: OSGi Installer 3.0.0, JCR Installer 3.0.0 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: OSGi Installer 3.0.0, JCR Installer 3.0.0 > > > In order to fix some outstanding bugs and to add new features, a code review > and clean up seems to be a good idea :) > This bug will keep track of all changes to the code that don't add new > features -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1593) Decouple authentication mechanism from JCR
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898282#action_12898282 ] Mike Müller commented on SLING-1593: I'm not very happy that the validation of credentials should be done in the ResourceResolverFactory. The ResourceResolverFactory should stick to what it's name makes us believe it is doing: create a ResourceResolver (Single Responsibility Principle). Furthermore I can't see any disadvantages in applying the CredentialsValidator here as long as the interface is in the spi package and not part of the Sling API. In this patch there's also the change to the JcrSessionCollector which collects old JCR sessions (with the help of the SlingRequestListener) to logout them if needed. I think this is a much cleaner approach than before. > Decouple authentication mechanism from JCR > -- > > Key: SLING-1593 > URL: https://issues.apache.org/jira/browse/SLING-1593 > Project: Sling > Issue Type: Improvement > Components: API, Commons, JCR >Reporter: Mike Müller >Assignee: Mike Müller > Fix For: Commons Auth 1.0.0 > > Attachments: sling-1593.patch > > > Felix made a good proposal how to decouple the authentication mechanism from > JCR at [1] after the discussion at [2]. The remaining issue there was how to > ensure JCR sessions which are placed into AuthenticationInfo be closed. To > solve that issue we now can use the new SlingRequestListener [3]. > [1] https://cwiki.apache.org/SLING/user-authentication.html > [2] http://markmail.org/message/aovh7lll4w6uwepv > [3] https://issues.apache.org/jira/browse/SLING-1576 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1295) JcrInstall should only observe configured folders
[ https://issues.apache.org/jira/browse/SLING-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1295. - Resolution: Invalid This issue is invalid > JcrInstall should only observe configured folders > - > > Key: SLING-1295 > URL: https://issues.apache.org/jira/browse/SLING-1295 > Project: Sling > Issue Type: Improvement > Components: Installer >Reporter: Carsten Ziegeler > > Currently jcr install listens for all modifications in the repository - > however only changes to the configured locations are of interest, therefore > jcr install > should register more specific listeners for the various configured paths. > This can be done by registering event listener proxy that all forward the > events to a single listener -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1488) Move EventHelper from JCRInstall to Commons Testing
[ https://issues.apache.org/jira/browse/SLING-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1488. - Resolution: Fixed Removed class from jcr install in revision 985245 > Move EventHelper from JCRInstall to Commons Testing > --- > > Key: SLING-1488 > URL: https://issues.apache.org/jira/browse/SLING-1488 > Project: Sling > Issue Type: Improvement > Components: Commons, Installer >Reporter: Justin Edelson >Assignee: Justin Edelson >Priority: Minor > Fix For: JCR Installer 3.0.0, Commons Testing 2.0.6 > > Original Estimate: 0h > Remaining Estimate: 0h > > There's an EventHelper class in JCRInstall's test directory which is of > general use. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1648) Node move with :replace fails
[ https://issues.apache.org/jira/browse/SLING-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-1648: Affects Version/s: Servlets Post 2.0.4 Component/s: Servlets > Node move with :replace fails > - > > Key: SLING-1648 > URL: https://issues.apache.org/jira/browse/SLING-1648 > Project: Sling > Issue Type: Bug > Components: Servlets >Affects Versions: Servlets Post 2.0.4 >Reporter: daniel parry > > Following docs at > http://sling.apache.org/site/manipulating-content-the-slingpostservlet-servletspost.html > In trunk, Revision: 984520, steps to reproduce error: > curl -uadmin:admin -Ftitle="test" -Ftext="test" http://localhost:8080/test1 > curl -uadmin:admin -Ftitle="test" -Ftext="test" http://localhost:8080/test2 > curl -uadmin:admin -F":operation=move" -F:dest="/test2" > http://localhost:8080/test1 (Not allowed to move without :replace as expected) > curl -uadmin:admin -F":operation=move" -F":replace=true" -F:dest="/test2" > http://localhost:8080/test1 (This should work with :replace specified) > However, error encountered: > > > Error while processing /test1 > > > Error while processing /test1 > > > > Status > 500 > > > Message > javax.jcr.PathNotFoundException: > /test2 > > > Location > /test1 > > > Parent Location > / > > > Path > /test1 > > > Referer > > > > ChangeLog > > > > > Go Back > Modified Resource > Parent of Modified Resource > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1513) allow host-specific rendering for virtual hosts. "Multitenancy Support"
[ https://issues.apache.org/jira/browse/SLING-1513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-1513: Component/s: API > allow host-specific rendering for virtual hosts. "Multitenancy Support" > --- > > Key: SLING-1513 > URL: https://issues.apache.org/jira/browse/SLING-1513 > Project: Sling > Issue Type: New Feature > Components: API >Reporter: Markus Blaurock > > Currently we have the need to run multiple websites on the same > sling-instance. That is, serving the same or similar content in > different ways (layouts), defined by the hostname. > Reason behind this is we would like to have a single pool of > sling-app-servers and > each one should be possible to serve all websites. Otherwise we would > need to have one pool for each (small) site, which is not feasible. > e.g. Content "a/b/c" should be accessible with > http://www.one/a/b/c.html > and > http://www.two/a/b/c.html > and looking differently. > https://cwiki.apache.org/SLING/multitenancy-support.html would solve the > problem easily. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[HEADSUP] Sling API 2.1 Release
Hi all, Looking at [1] there are no more open issues for the Sling API. I have published a "mvn site" run to my people folder [2]. So please quickly check this and your portfolios for any missing links. If I hear nothing to the contrary I will cut the release on Monday. Regards Felix [1] https://issues.apache.org/jira/browse/SLING/fixforversion/12314252 [2] http://people.apache.org/~fmeschbe/sling6/api/
Re: Preparing for a 3.0.2 release of framework
Hi all, I have updated Sling Launchpad base to this SNAPSHOT version in anticipation of this release and to give it some exposure. Please report any problems you might run into. Thanks. Regards Felix On 13.08.2010 16:23, Richard S. Hall wrote: > We're going to do a 3.0.2 release of the framework, since we have a > fair number of reasonably minor, but worthwhile changes in trunk. The > biggest change is in some locking code around our installed bundle data > structures, which was done to try to resolve FELIX-2437. > > I've published snapshot (including the framework distro), so go ahead > and play with it. Thanks. > > -> richard >
[jira] Issue Comment Edited: (SLING-1652) Upgrade Felix Framework to latest release
[ https://issues.apache.org/jira/browse/SLING-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898252#action_12898252 ] Felix Meschberger edited comment on SLING-1652 at 8/13/10 10:36 AM: Upgraded to 3.1.0-SNAPSHOT in in Rev. 985208 was (Author: fmeschbe): Done in Rev. 985208 > Upgrade Felix Framework to latest release > - > > Key: SLING-1652 > URL: https://issues.apache.org/jira/browse/SLING-1652 > Project: Sling > Issue Type: Task > Components: Launchpad >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: Launchpad Base 2.2.2 > > > Richard Hall hall published a 3.1.0-SNAPSHOT release to give the framework > exposure before the 3.0.2 release to come in the short time frame. The Base > module should be upgraded to this snapshot to test the snapshot and as soon > as 3.0.2 is released, upgrade to that release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (SLING-1652) Upgrade Felix Framework to latest release
[ https://issues.apache.org/jira/browse/SLING-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reopened SLING-1652: -- Reopen. This issue should only be resolved when the final version is actually referred to > Upgrade Felix Framework to latest release > - > > Key: SLING-1652 > URL: https://issues.apache.org/jira/browse/SLING-1652 > Project: Sling > Issue Type: Task > Components: Launchpad >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: Launchpad Base 2.2.2 > > > Richard Hall hall published a 3.1.0-SNAPSHOT release to give the framework > exposure before the 3.0.2 release to come in the short time frame. The Base > module should be upgraded to this snapshot to test the snapshot and as soon > as 3.0.2 is released, upgrade to that release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1652) Upgrade Felix Framework to latest release
Upgrade Felix Framework to latest release - Key: SLING-1652 URL: https://issues.apache.org/jira/browse/SLING-1652 Project: Sling Issue Type: Task Components: Launchpad Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Launchpad Base 2.2.2 Richard Hall hall published a 3.1.0-SNAPSHOT release to give the framework exposure before the 3.0.2 release to come in the short time frame. The Base module should be upgraded to this snapshot to test the snapshot and as soon as 3.0.2 is released, upgrade to that release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1652) Upgrade Felix Framework to latest release
[ https://issues.apache.org/jira/browse/SLING-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-1652. -- Resolution: Fixed Done in Rev. 985208 > Upgrade Felix Framework to latest release > - > > Key: SLING-1652 > URL: https://issues.apache.org/jira/browse/SLING-1652 > Project: Sling > Issue Type: Task > Components: Launchpad >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: Launchpad Base 2.2.2 > > > Richard Hall hall published a 3.1.0-SNAPSHOT release to give the framework > exposure before the 3.0.2 release to come in the short time frame. The Base > module should be upgraded to this snapshot to test the snapshot and as soon > as 3.0.2 is released, upgrade to that release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Moving the Commons Auth Bundle
+1 to moving auth out of commons and moving the other auth bundles to bundles/auth. Not loving the package change, but I agree it is a good idea and better to be done now than later. On Aug 13, 2010, at 10:01 AM, Felix Meschberger wrote: > Hi all, > > We are in the end game of releasing the Sling Authenticator Bundle (aka > Commons Auth). > > Carsten an I have been discussing about this bundle and are considering > moving this bundle out of the commons area. > > The reason for this is, that the commons area has once been designated > to be a location with usefull helper stuff but with not API dependency > to Sling. Since we moved part of Commons Auth to the API, this does not > hold any longer for the Commons Auth bundle. > > As a consequence, we would have to rename the packages from > o.a.s.commons.auth to o.a.s.auth (probably). This is mainly an issue > because the exported packages ...auth and ...auth.spi are being used > elsewhere (e.g. for implementing authentication handlers). > > I suggest we create a new location bundles/auth where we move the > Authenticator bundle along with the OpenID and Form authentication > handlers (currently below bundles/extensions). > > As a consequence the API packages o.a.s.commons.auth and > o.a.s.commons.auth.spi would be renamed to o.a.s.auth and > o.a.s.auth.spi, resp. > > Moving the bundle is tracked in SLING-1650. > > WDYT ? > > Regards > Felix > > [1] https://issues.apache.org/jira/browse/SLING-1650
Moving the Commons Auth Bundle
Hi all, We are in the end game of releasing the Sling Authenticator Bundle (aka Commons Auth). Carsten an I have been discussing about this bundle and are considering moving this bundle out of the commons area. The reason for this is, that the commons area has once been designated to be a location with usefull helper stuff but with not API dependency to Sling. Since we moved part of Commons Auth to the API, this does not hold any longer for the Commons Auth bundle. As a consequence, we would have to rename the packages from o.a.s.commons.auth to o.a.s.auth (probably). This is mainly an issue because the exported packages ...auth and ...auth.spi are being used elsewhere (e.g. for implementing authentication handlers). I suggest we create a new location bundles/auth where we move the Authenticator bundle along with the OpenID and Form authentication handlers (currently below bundles/extensions). As a consequence the API packages o.a.s.commons.auth and o.a.s.commons.auth.spi would be renamed to o.a.s.auth and o.a.s.auth.spi, resp. Moving the bundle is tracked in SLING-1650. WDYT ? Regards Felix [1] https://issues.apache.org/jira/browse/SLING-1650
[jira] Updated: (SLING-1650) Move commons auth to another location
[ https://issues.apache.org/jira/browse/SLING-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1650: - Summary: Move commons auth to another location (was: Move commons auth to extensions) Description: As the commons auth uses the Sling API it is by definition no commons module :) Therefore it should be moved to some other location e.g. bundles/extensions or a new location bundles/auth where also the OpenID and Form authentication handlers could be moved to keep them together. was: As the commons auth uses the Sling API it is by definition no commons module :) Therefore it should be moved to the extensions part Component/s: (was: Extensions) > Move commons auth to another location > - > > Key: SLING-1650 > URL: https://issues.apache.org/jira/browse/SLING-1650 > Project: Sling > Issue Type: Task > Components: Commons >Affects Versions: Commons Auth 1.0.0 >Reporter: Carsten Ziegeler >Assignee: Felix Meschberger > Fix For: Commons Auth 1.0.0 > > > As the commons auth uses the Sling API it is by definition no commons module > :) > Therefore it should be moved to some other location e.g. bundles/extensions > or a new location bundles/auth where also the OpenID and Form authentication > handlers could be moved to keep them together. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: extending jQuery JCR Resource explorer
On Aug 13, 2010, at 3:55 AM, Clemens Wyss wrote: > will I be able to update/add/delete the values of multivalued properties > through the Sling REST API (SlingPostServlet?)? Yes. You need to set the property as a whole, i.e. pass all values for a property in a same post. There's no way to say "delete the third value from the baz property /content/foo/bar". > >> -Original Message- >> From: Clemens Wyss [mailto:clemens...@mysign.ch] >> Sent: Friday, August 13, 2010 7:22 AM >> To: 'dev@sling.apache.org' >> Subject: RE: extending jQuery JCR Resource explorer >> >> >>> 2, 4, 5, 6, 10 >> ok, so you think/say "mixin types" is not that much a topic? >> >>> ACL view/edit >> good point, though this mandates 10) ;-) >> >>> Reference/Path property support >> Links? drag&drop? >> >>> I need to make some modifications to the explorer to support >>> non-default workspaces, but hopefully that change will be >>> minor (keeps slipping off my list). >> is there a jira entry for this task? >> >> Is esp the right serverside approach? Or would groovy (me, >> coming from Ruby), or even Java be "helpful"? >> >> Clemens >> >>> -Original Message- >>> From: Justin Edelson [mailto:justinedel...@gmail.com] >>> Sent: Thursday, August 12, 2010 9:07 PM >>> To: dev@sling.apache.org >>> Subject: Re: extending jQuery JCR Resource explorer >>> >>> >>> Nice of you to ask about prioritization... >>> >>> 2, 4, 5, 6, 10 >>> >>> Would be the highest priority items for me. I'd also add >>> these to your list: >>> >>> ACL view/edit >>> Reference/Path property support >>> >>> I need to make some modifications to the explorer to support >>> non-default workspaces, but hopefully that change will be >>> minor (keeps slipping off my list). >>> >>> Justin >>> >>> >>> On Aug 12, 2010, at 10:26 AM, Clemens Wyss >>> wrote: >>> As "promised", I (actually it's we, MySign) intend to >>> extend the jQuery JCR Resource (contrib/explorers/jQuery) >>> explorer in order to make it more valuable for developers. Features currently available (as of May 17th 2010, rev 945149): + login + browse JCR + add node (name, sling:resourceType and jcr:primaryType >>> have to be entered manually (input field)) + delete node + view properties (multivalue properties are shown "inline" >>> in an input field) + modify/update property (single value properties only) + delete property desirable features: 1) jcr:primaryNodeType properties should be selectable 2) view/add/edit/delete multivalued properties 3) view/add/edit/delete mixin types, mixin types should be >>> selectable 4) simplified input for "known types", such as date (see >>> also 1) and 3) ) 5) search/filter functionality (SQL2, JQOM?) 6) nt:file -> file upload 7) import/export subtrees, format to be defined 8) input validation 9) ajax'ify the client 10) usermanagement more to come... WDYT? Anything important/fancy missing? How would you >>> priorize these features? >>> >>
Re: extending jQuery JCR Resource explorer
On Aug 13, 2010, at 1:22 AM, Clemens Wyss wrote: >> 2, 4, 5, 6, 10 > ok, so you think/say "mixin types" is not that much a topic? Hmm. I'm not aware that you can't set a mixin type today, but yes... in my usage of this explorer, I've never found myself wanting to add a mixin. But YMMV. > >> ACL view/edit > good point, though this mandates 10) ;-) Yes > >> Reference/Path property support > Links? drag&drop? Display should be links. To add a value, I'd love a browse/search popup, but that's just me. > >> I need to make some modifications to the explorer to support >> non-default workspaces, but hopefully that change will be >> minor (keeps slipping off my list). > is there a jira entry for this task? No. > > Is esp the right serverside approach? Or would groovy (me, coming from Ruby), > or even Java be "helpful"? I think esp is used currently, so there's that to consider. Also, you can use (J)Ruby if you want; the jruby-all JAR just needs to installed. Mostly, I imagine the amount of new server side code to be minimal. Justin > > Clemens > >> -Original Message- >> From: Justin Edelson [mailto:justinedel...@gmail.com] >> Sent: Thursday, August 12, 2010 9:07 PM >> To: dev@sling.apache.org >> Subject: Re: extending jQuery JCR Resource explorer >> >> >> Nice of you to ask about prioritization... >> >> 2, 4, 5, 6, 10 >> >> Would be the highest priority items for me. I'd also add >> these to your list: >> >> ACL view/edit >> Reference/Path property support >> >> I need to make some modifications to the explorer to support >> non-default workspaces, but hopefully that change will be >> minor (keeps slipping off my list). >> >> Justin >> >> >> On Aug 12, 2010, at 10:26 AM, Clemens Wyss >> wrote: >> >>> As "promised", I (actually it's we, MySign) intend to >> extend the jQuery JCR Resource (contrib/explorers/jQuery) >> explorer in order to make it more valuable for developers. >>> >>> Features currently available (as of May 17th 2010, rev 945149): >>> + login >>> + browse JCR >>> + add node (name, sling:resourceType and jcr:primaryType >> have to be entered manually (input field)) >>> + delete node >>> + view properties (multivalue properties are shown "inline" >> in an input field) >>> + modify/update property (single value properties only) >>> + delete property >>> >>> desirable features: >>> 1) jcr:primaryNodeType properties should be selectable >>> 2) view/add/edit/delete multivalued properties >>> 3) view/add/edit/delete mixin types, mixin types should be >> selectable >>> 4) simplified input for "known types", such as date (see >> also 1) and 3) ) >>> 5) search/filter functionality (SQL2, JQOM?) >>> 6) nt:file -> file upload >>> 7) import/export subtrees, format to be defined >>> 8) input validation >>> 9) ajax'ify the client >>> 10) usermanagement >>> more to come... >>> >>> WDYT? Anything important/fancy missing? How would you >> priorize these features? >>
[jira] Assigned: (SLING-1650) Move commons auth to extensions
[ https://issues.apache.org/jira/browse/SLING-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned SLING-1650: Assignee: Felix Meschberger > Move commons auth to extensions > --- > > Key: SLING-1650 > URL: https://issues.apache.org/jira/browse/SLING-1650 > Project: Sling > Issue Type: Task > Components: Commons, Extensions >Affects Versions: Commons Auth 1.0.0 >Reporter: Carsten Ziegeler >Assignee: Felix Meschberger > Fix For: Commons Auth 1.0.0 > > > As the commons auth uses the Sling API it is by definition no commons module > :) > Therefore it should be moved to the extensions part -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1560) Improve and clean up code
[ https://issues.apache.org/jira/browse/SLING-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898197#action_12898197 ] Carsten Ziegeler commented on SLING-1560: - Merge installer impl and thread, make registered resources comparable > Improve and clean up code > - > > Key: SLING-1560 > URL: https://issues.apache.org/jira/browse/SLING-1560 > Project: Sling > Issue Type: Improvement > Components: Installer >Affects Versions: OSGi Installer 3.0.0, JCR Installer 3.0.0 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: OSGi Installer 3.0.0, JCR Installer 3.0.0 > > > In order to fix some outstanding bugs and to add new features, a code review > and clean up seems to be a good idea :) > This bug will keep track of all changes to the code that don't add new > features -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1651) Integrate RunMode module into new Settings Module
[ https://issues.apache.org/jira/browse/SLING-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1651. - Resolution: Fixed Added run mode stuff to the settings service and added web configuration printer and shell command > Integrate RunMode module into new Settings Module > - > > Key: SLING-1651 > URL: https://issues.apache.org/jira/browse/SLING-1651 > Project: Sling > Issue Type: Task > Components: Engine >Affects Versions: Extensions Settings 0.1.0 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Extensions Settings 0.1.0 > > > To keep all settings related stuff in a single central place, we should merge > the current run mode module into the settings module -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-983) Add sling.properties file to configuration status page
[ https://issues.apache.org/jira/browse/SLING-983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-983. Fix Version/s: Extensions Settings 0.1.0 (was: Engine 2.1.0) Resolution: Fixed Moved to the new settings module and removed from engine > Add sling.properties file to configuration status page > -- > > Key: SLING-983 > URL: https://issues.apache.org/jira/browse/SLING-983 > Project: Sling > Issue Type: Improvement > Components: Engine >Affects Versions: Launchpad Base 2.1.0 >Reporter: Felix Meschberger >Assignee: Carsten Ziegeler > Fix For: Extensions Settings 0.1.0, Launchpad Base 2.2.0 > > > It would be good, if the sling.properties file could be provided through a > Felix Web Console ConfigurationPrinter to include it into the Configuration > Status output to ease support. > Maybe this would be part of the Sling Engine bundle, which is the "core > engine" of Sling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1462) Add methods to get the sling home to SlingSettingsService
[ https://issues.apache.org/jira/browse/SLING-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1462. - Fix Version/s: Extensions Settings 0.1.0 (was: API 2.1.0) (was: Engine 2.1.0) Resolution: Fixed Moved to new settings module > Add methods to get the sling home to SlingSettingsService > - > > Key: SLING-1462 > URL: https://issues.apache.org/jira/browse/SLING-1462 > Project: Sling > Issue Type: Improvement > Components: API, Engine >Affects Versions: Engine 2.0.6, API 2.0.8 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Extensions Settings 0.1.0 > > > Add some methods to the new SlingSettingService in the API to get the Sling > home directory as a string and a url object. > The constants for these properties should be added to the API constants as > well - and the constants in the engine should be deprecated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (SLING-1462) Add methods to get the sling home to SlingSettingsService
[ https://issues.apache.org/jira/browse/SLING-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reopened SLING-1462: - Reopening as this is now part of the Settings module > Add methods to get the sling home to SlingSettingsService > - > > Key: SLING-1462 > URL: https://issues.apache.org/jira/browse/SLING-1462 > Project: Sling > Issue Type: Improvement > Components: API, Engine >Affects Versions: Engine 2.0.6, API 2.0.8 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Engine 2.1.0, API 2.1.0 > > > Add some methods to the new SlingSettingService in the API to get the Sling > home directory as a string and a url object. > The constants for these properties should be added to the API constants as > well - and the constants in the engine should be deprecated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1651) Integrate RunMode module into new Settings Module
Integrate RunMode module into new Settings Module - Key: SLING-1651 URL: https://issues.apache.org/jira/browse/SLING-1651 Project: Sling Issue Type: Task Components: Engine Affects Versions: Extensions Settings 0.1.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Extensions Settings 0.1.0 To keep all settings related stuff in a single central place, we should merge the current run mode module into the settings module -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (SLING-983) Add sling.properties file to configuration status page
[ https://issues.apache.org/jira/browse/SLING-983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reopened SLING-983: Reopening as this should be moved to the Settings module > Add sling.properties file to configuration status page > -- > > Key: SLING-983 > URL: https://issues.apache.org/jira/browse/SLING-983 > Project: Sling > Issue Type: Improvement > Components: Engine >Affects Versions: Launchpad Base 2.1.0 >Reporter: Felix Meschberger >Assignee: Carsten Ziegeler > Fix For: Launchpad Base 2.2.0, Engine 2.1.0 > > > It would be good, if the sling.properties file could be provided through a > Felix Web Console ConfigurationPrinter to include it into the Configuration > Status output to ease support. > Maybe this would be part of the Sling Engine bundle, which is the "core > engine" of Sling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1460) Move SlingSettingsService to new Settings bundle
[ https://issues.apache.org/jira/browse/SLING-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1460. - Resolution: Fixed Created new module and moved the service to this module. Updated all references. The new implementation reads a possibly available sling id from the engine bundle on startup for compatibility > Move SlingSettingsService to new Settings bundle > > > Key: SLING-1460 > URL: https://issues.apache.org/jira/browse/SLING-1460 > Project: Sling > Issue Type: Improvement > Components: Engine, Extensions >Affects Versions: Engine 2.0.6 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Engine 2.1.0, Extensions Settings 0.1.0 > > > As discussed in the mailinglist, the SlingSettings service should be moved to > the API bundle: > - Add the interface to the API in the o.a.s.api.services package > - Deprecate the interface in the enigne bundle and let it extend > from the interface in the API > - Let the service impl in the engine bundle register itself for > both interfaces. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SLING-1593) Decouple authentication mechanism from JCR
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898134#action_12898134 ] Felix Meschberger edited comment on SLING-1593 at 8/13/10 4:51 AM: --- Now that the Sling Authenticator is using the ResourceResolverFactory to create a ResourceResolver using the extracted credentials (or AuthenticationInfo) I would prefer to no apply this patch. If we want to add more functionality to the validation of credentials, I think we need a different ResourceResolverFactory implementing this. Now, currently the ResourceResolverFactory is implemented by the jcr/resource bundle, which contains both the ResourceResovlerFactory implementation as well as the JcrResourceProvider. To solve this we should probably separate the ResourceResolverFactory and ResourceResolver implementations into a separate bundle and just keep the JcrResourceProvider in the jcr/resource bundle. As it is described in https://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html Having said this, I would say https://cwiki.apache.org/SLING/user-authentication.html has been superceded with the ResourceResolverFactory interface in the Sling API (as a partial implementation of add-resourceresolverfactory-service-interface.html) was (Author: fmeschbe): Now that the Sling Authenticator is using the ResourceResolverFactory to create a ResourceResolver using the extracted credentials (or AuthenticationInfo) I would prefer to no apply this patch. If we want to add more functionality to the validation of credentials, I think we need a different ResourceResolverFactory implementing this. Now, currently the ResourceResolverFactory is implemented by the jcr/resource bundle, which contains both the ResourceResovlerFactory implementation as well as the JcrResourceProvider. To solve this we should probably separate the ResourceResolverFactory and ResourceResolver implementations into a separate bundle and just keep the JcrResourceProvider in the jcr/resource bundle. As it is described in https://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html > Decouple authentication mechanism from JCR > -- > > Key: SLING-1593 > URL: https://issues.apache.org/jira/browse/SLING-1593 > Project: Sling > Issue Type: Improvement > Components: API, Commons, JCR >Reporter: Mike Müller >Assignee: Mike Müller > Fix For: Commons Auth 1.0.0 > > Attachments: sling-1593.patch > > > Felix made a good proposal how to decouple the authentication mechanism from > JCR at [1] after the discussion at [2]. The remaining issue there was how to > ensure JCR sessions which are placed into AuthenticationInfo be closed. To > solve that issue we now can use the new SlingRequestListener [3]. > [1] https://cwiki.apache.org/SLING/user-authentication.html > [2] http://markmail.org/message/aovh7lll4w6uwepv > [3] https://issues.apache.org/jira/browse/SLING-1576 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1593) Decouple authentication mechanism from JCR
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898134#action_12898134 ] Felix Meschberger commented on SLING-1593: -- Now that the Sling Authenticator is using the ResourceResolverFactory to create a ResourceResolver using the extracted credentials (or AuthenticationInfo) I would prefer to no apply this patch. If we want to add more functionality to the validation of credentials, I think we need a different ResourceResolverFactory implementing this. Now, currently the ResourceResolverFactory is implemented by the jcr/resource bundle, which contains both the ResourceResovlerFactory implementation as well as the JcrResourceProvider. To solve this we should probably separate the ResourceResolverFactory and ResourceResolver implementations into a separate bundle and just keep the JcrResourceProvider in the jcr/resource bundle. As it is described in https://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html > Decouple authentication mechanism from JCR > -- > > Key: SLING-1593 > URL: https://issues.apache.org/jira/browse/SLING-1593 > Project: Sling > Issue Type: Improvement > Components: API, Commons, JCR >Reporter: Mike Müller >Assignee: Mike Müller > Fix For: Commons Auth 1.0.0 > > Attachments: sling-1593.patch > > > Felix made a good proposal how to decouple the authentication mechanism from > JCR at [1] after the discussion at [2]. The remaining issue there was how to > ensure JCR sessions which are placed into AuthenticationInfo be closed. To > solve that issue we now can use the new SlingRequestListener [3]. > [1] https://cwiki.apache.org/SLING/user-authentication.html > [2] http://markmail.org/message/aovh7lll4w6uwepv > [3] https://issues.apache.org/jira/browse/SLING-1576 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1650) Move commons auth to extensions
Move commons auth to extensions --- Key: SLING-1650 URL: https://issues.apache.org/jira/browse/SLING-1650 Project: Sling Issue Type: Task Components: Commons, Extensions Affects Versions: Commons Auth 1.0.0 Reporter: Carsten Ziegeler Fix For: Commons Auth 1.0.0 As the commons auth uses the Sling API it is by definition no commons module :) Therefore it should be moved to the extensions part -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: extending jQuery JCR Resource explorer
Hi, On 13.08.2010 07:59, Clemens Wyss wrote: >> Take care of maintainability ;-) > +1, so either esp or groovy. Will proceed with esp for the moment > >> Just my CHF 0.02 really. > we both know there is at minimum the CHF 0.05 :-) I still have some of those CHF 0.01 and 0.02 coins, though ;-) > > maven question: > I'd like to make use of "-P autoInstBundle" to speed up the development > cycle. What needs to be modified/added in the pom.xml to be able to?: > mvn -P autoInstallBundle package > -Dsling.url=http://localhost:8080/system/console > > Tried to add "../../parent/pom.xml" to the > -element, but no success. Any hint/help appreciated. Referring to a recent Sling Parent POM is all that's needed. The rest should have reasonable defaults for a default sling launch. If your using a different port, you will have to set the sling.url property, yes. Regards Felix > >> -Original Message- >> From: Felix Meschberger [mailto:fmesc...@gmail.com] >> Sent: Friday, August 13, 2010 7:35 AM >> To: dev@sling.apache.org >> Subject: Re: extending jQuery JCR Resource explorer >> >> >> Hi, >> >> On 13.08.2010 07:22, Clemens Wyss wrote: 2, 4, 5, 6, 10 >>> ok, so you think/say "mixin types" is not that much a topic? >>> ACL view/edit >>> good point, though this mandates 10) ;-) >>> Reference/Path property support >>> Links? drag&drop? >>> I need to make some modifications to the explorer to support non-default workspaces, but hopefully that change will be minor (keeps slipping off my list). >>> is there a jira entry for this task? >>> >>> Is esp the right serverside approach? Or would groovy (me, >> coming from Ruby), or even Java be "helpful"? >> >> Basically: Whatever you like and can be supported with JSR-223 (Java >> Script API). >> >> If you choose groovy, fine. That's included with Sling already. If you >> chose Java, fine. If you choose ESP or ECMA, fine. >> >> One part of my heart even says: If you use multiple languages for this >> on the server-side it would be a nice example for the versatility of >> scripting support in Sling ... The other part of my heart says: Take >> care of maintainability ;-) >> >> Just my CHF 0.02 really. >> >> Regards >> Felix >> >>> >>> Clemens >>> -Original Message- From: Justin Edelson [mailto:justinedel...@gmail.com] Sent: Thursday, August 12, 2010 9:07 PM To: dev@sling.apache.org Subject: Re: extending jQuery JCR Resource explorer Nice of you to ask about prioritization... 2, 4, 5, 6, 10 Would be the highest priority items for me. I'd also add these to your list: ACL view/edit Reference/Path property support I need to make some modifications to the explorer to support non-default workspaces, but hopefully that change will be minor (keeps slipping off my list). Justin On Aug 12, 2010, at 10:26 AM, Clemens Wyss wrote: > As "promised", I (actually it's we, MySign) intend to extend the jQuery JCR Resource (contrib/explorers/jQuery) explorer in order to make it more valuable for developers. > > Features currently available (as of May 17th 2010, rev 945149): > + login > + browse JCR > + add node (name, sling:resourceType and jcr:primaryType have to be entered manually (input field)) > + delete node > + view properties (multivalue properties are shown "inline" in an input field) > + modify/update property (single value properties only) > + delete property > > desirable features: > 1) jcr:primaryNodeType properties should be selectable > 2) view/add/edit/delete multivalued properties > 3) view/add/edit/delete mixin types, mixin types should be selectable > 4) simplified input for "known types", such as date (see also 1) and 3) ) > 5) search/filter functionality (SQL2, JQOM?) > 6) nt:file -> file upload > 7) import/export subtrees, format to be defined > 8) input validation > 9) ajax'ify the client > 10) usermanagement > more to come... > > WDYT? Anything important/fancy missing? How would you priorize these features? >>> >>
RE: extending jQuery JCR Resource explorer
will I be able to update/add/delete the values of multivalued properties through the Sling REST API (SlingPostServlet?)? > -Original Message- > From: Clemens Wyss [mailto:clemens...@mysign.ch] > Sent: Friday, August 13, 2010 7:22 AM > To: 'dev@sling.apache.org' > Subject: RE: extending jQuery JCR Resource explorer > > > > 2, 4, 5, 6, 10 > ok, so you think/say "mixin types" is not that much a topic? > > > ACL view/edit > good point, though this mandates 10) ;-) > > > Reference/Path property support > Links? drag&drop? > > > I need to make some modifications to the explorer to support > > non-default workspaces, but hopefully that change will be > > minor (keeps slipping off my list). > is there a jira entry for this task? > > Is esp the right serverside approach? Or would groovy (me, > coming from Ruby), or even Java be "helpful"? > > Clemens > > > -Original Message- > > From: Justin Edelson [mailto:justinedel...@gmail.com] > > Sent: Thursday, August 12, 2010 9:07 PM > > To: dev@sling.apache.org > > Subject: Re: extending jQuery JCR Resource explorer > > > > > > Nice of you to ask about prioritization... > > > > 2, 4, 5, 6, 10 > > > > Would be the highest priority items for me. I'd also add > > these to your list: > > > > ACL view/edit > > Reference/Path property support > > > > I need to make some modifications to the explorer to support > > non-default workspaces, but hopefully that change will be > > minor (keeps slipping off my list). > > > > Justin > > > > > > On Aug 12, 2010, at 10:26 AM, Clemens Wyss > > wrote: > > > > > As "promised", I (actually it's we, MySign) intend to > > extend the jQuery JCR Resource (contrib/explorers/jQuery) > > explorer in order to make it more valuable for developers. > > > > > > Features currently available (as of May 17th 2010, rev 945149): > > > + login > > > + browse JCR > > > + add node (name, sling:resourceType and jcr:primaryType > > have to be entered manually (input field)) > > > + delete node > > > + view properties (multivalue properties are shown "inline" > > in an input field) > > > + modify/update property (single value properties only) > > > + delete property > > > > > > desirable features: > > > 1) jcr:primaryNodeType properties should be selectable > > > 2) view/add/edit/delete multivalued properties > > > 3) view/add/edit/delete mixin types, mixin types should be > > selectable > > > 4) simplified input for "known types", such as date (see > > also 1) and 3) ) > > > 5) search/filter functionality (SQL2, JQOM?) > > > 6) nt:file -> file upload > > > 7) import/export subtrees, format to be defined > > > 8) input validation > > > 9) ajax'ify the client > > > 10) usermanagement > > > more to come... > > > > > > WDYT? Anything important/fancy missing? How would you > > priorize these features? > > >
[jira] Reopened: (SLING-1460) Move SlingSettingsService to API bundle
[ https://issues.apache.org/jira/browse/SLING-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reopened SLING-1460: - As mentioned in the mailing list, reopening this issue. This service should not be part of the Sling API but a new module with the settings service. The run mode stuff will be merged into this bundle as well. > Move SlingSettingsService to API bundle > --- > > Key: SLING-1460 > URL: https://issues.apache.org/jira/browse/SLING-1460 > Project: Sling > Issue Type: Improvement > Components: Engine, Extensions >Affects Versions: Engine 2.0.6 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Engine 2.1.0, Settings 0.1.0 > > > As discussed in the mailinglist, the SlingSettings service should be moved to > the API bundle: > - Add the interface to the API in the o.a.s.api.services package > - Deprecate the interface in the enigne bundle and let it extend > from the interface in the API > - Let the service impl in the engine bundle register itself for > both interfaces. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1460) Move SlingSettingsService to new Settings bundle
[ https://issues.apache.org/jira/browse/SLING-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-1460: Summary: Move SlingSettingsService to new Settings bundle (was: Move SlingSettingsService to API bundle) Fix Version/s: Settings 0.1.0 (was: API 2.1.0) Affects Version/s: (was: API 2.0.8) Component/s: Extensions (was: API) > Move SlingSettingsService to new Settings bundle > > > Key: SLING-1460 > URL: https://issues.apache.org/jira/browse/SLING-1460 > Project: Sling > Issue Type: Improvement > Components: Engine, Extensions >Affects Versions: Engine 2.0.6 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Engine 2.1.0, Settings 0.1.0 > > > As discussed in the mailinglist, the SlingSettings service should be moved to > the API bundle: > - Add the interface to the API in the o.a.s.api.services package > - Deprecate the interface in the enigne bundle and let it extend > from the interface in the API > - Let the service impl in the engine bundle register itself for > both interfaces. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1193) Extend Resource interface and provide AbstractResource base class
[ https://issues.apache.org/jira/browse/SLING-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-1193. -- Resolution: Fixed This can now be resolved again after fixing and testing this. > Extend Resource interface and provide AbstractResource base class > - > > Key: SLING-1193 > URL: https://issues.apache.org/jira/browse/SLING-1193 > Project: Sling > Issue Type: New Feature > Components: API, Engine, JCR, Scripting, Servlets >Affects Versions: Servlets Resolver 2.0.8, Scripting Core 2.0.10, JCR > Resource 2.0.6, Engine 2.0.6, API 2.0.8 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: Servlets Resolver 2.0.10, Scripting Core 2.0.12, JCR > Resource 2.0.8, File System Resource Provider 1.0.2, Extensions > Bundleresource 2.0.6, Engine 2.1.0, API 2.1.0 > > > Currently the Resource interface has only bare bones API to access its own > local attributes, like getPath() or getResourceType(). > Accessing the resource in the context of its parent or its children is not > currently possible and doing so requires getting the resource resolver out of > the resource and asking the resource resolver. > For convenience, we should add the following methods: >getParent() -- returns the parent resource (same as > ResourceUtil.getParent(this)) >getName() -- returns the name of the resource (same as > ResourceUtil.getName(this)) >listChildren() -- same as getResourceResolver().listChildren(this) >getChild(String) -- same as getResourceResolver().getResource(this, path) >isResourceType(String) -- same as ResourceUtil.isA(this, String) > The new AbstractResource class will implement these methods as indicated. > Implementors of the Resource interface are then advised to actually extend > from the AbstractResource interface, which in the future will provide default > implementations of any methods added to the Resource interface, if it makes > sense. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1640) Add ResourceResolver.clone(Map) method
[ https://issues.apache.org/jira/browse/SLING-1640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-1640. -- Resolution: Fixed This has been implemented and passes the tests. Thus resolving. > Add ResourceResolver.clone(Map) method > --- > > Key: SLING-1640 > URL: https://issues.apache.org/jira/browse/SLING-1640 > Project: Sling > Issue Type: New Feature > Components: API, JCR >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: JCR Resource 2.0.8, API 2.1.0 > > > As discussed on the list the ResourceResolver interface should be extended > with a new method: > ResourceResolver clone(Map credentials); > This method creates a new ResourceResolver as follows: > // start with original credentials > Map newCredentials = new HashMap(current resolver credentials); > // overlay with provided credentials > newCredentials.addAll(credentials); > // return a new ResourceResolver > return resourceResolverFactory.login(newCredentials); > This new method allows for the removal of the AuthenticationInfo object from > the request attributes (as discussed in SLING-1445) and allows for a better > implementation of the background servlet execution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
