[jira] Created: (SLING-896) Allow installation of Sling as a feature in ServiceMix Kernel
Allow installation of Sling as a feature in ServiceMix Kernel - Key: SLING-896 URL: https://issues.apache.org/jira/browse/SLING-896 Project: Sling Issue Type: New Feature Components: Extensions Reporter: Sebastian Gomez Priority: Minor Sling works perfectly in ServiceMix Kernel if we add one by one all the bundles the launchpad needs in the correct order (depending on the start level), but there is a much easier way of doing this by creating what's called a feature in ServiceMix. This is a group of bundles that will be deployed in the order specified that will give the Kernel a new functionality. The installation of Sling as a feature in ServiceMix would be done in just two lines, without the need of copying bundles from one folder to another: s...@root:/features/addUrl mvn:my.groupId/sling-feature/1.0.0-SNAPSHOT/xml/features s...@root:/features/install sling I'll attach ASAP a patch with the necessary files to use Sling as a feature in ServiceMix Kernel. Hope both commiters and users find the patch useful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-896) Allow installation of Sling as a feature in ServiceMix Kernel
[ https://issues.apache.org/jira/browse/SLING-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Gomez updated SLING-896: -- Attachment: sling-feature.zip Uploaded patch with necessary files to deploy Sling as a ServiceMix feature. Allow installation of Sling as a feature in ServiceMix Kernel - Key: SLING-896 URL: https://issues.apache.org/jira/browse/SLING-896 Project: Sling Issue Type: New Feature Components: Extensions Reporter: Sebastian Gomez Priority: Minor Attachments: sling-feature.zip Sling works perfectly in ServiceMix Kernel if we add one by one all the bundles the launchpad needs in the correct order (depending on the start level), but there is a much easier way of doing this by creating what's called a feature in ServiceMix. This is a group of bundles that will be deployed in the order specified that will give the Kernel a new functionality. The installation of Sling as a feature in ServiceMix would be done in just two lines, without the need of copying bundles from one folder to another: s...@root:/features/addUrl mvn:my.groupId/sling-feature/1.0.0-SNAPSHOT/xml/features s...@root:/features/install sling I'll attach ASAP a patch with the necessary files to use Sling as a feature in ServiceMix Kernel. Hope both commiters and users find the patch useful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: OSGI pluggability in Sling
Hi. I'm not sure if this is the best place to write to, but I've been able to use Sling in ServiceMix Kernel without much problems, and have created a patch to deploy it as a ServiceMix Kernel feature. I've attached the patch to the following JIRA issue: https://issues.apache.org/jira/browse/SLING-896 I assume it would be quite useful for users to be able to use this patch, because it allows the deployment of Sling in ServiceMix Kernel by executing just two lines, so I'd appreciate you commiters including it maybe in the contrib section of the project. Sebastian Gomez. On Mon, Mar 23, 2009 at 2:10 PM, Carsten Ziegeler cziege...@apache.orgwrote: Felix Meschberger wrote: What about creating a deployment package? I knew you would mention that ;-) Sure, this would also be a good idea, of course -- In fact it is a far better idea than the dummy bundle -- and I constantly forget about it. :) There is already a maven plugin in my Apache Felix sandbox, so maybe we could start using that one and fix bugs and improve it as we need it. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Sling with Pax 0.2.3 does not work?
Changes have been applied in revision 757774. Feedback will be appreciate in order to close this issue [1]. Hi Juanjo. I deployed Sling with your changes on ServiceMix Kernel (pax-web-bundle 0.4.1) and it now works perfectly. Thank you very much. Sebastian Gomez. 2009/3/24 Juan José Vázquez Delgado juanjo.vazq...@gmail.com 2) Is there some way to publish the SlingMainServlet in a different context path than /? I've seen it hard wired to it, but I guess it may be a good idea to have it configurable in case Sling lives in a container with other web applications (such as my case in ServiceMix Kernel). I´m not sure if registration to the root has to be mandatory or not. Does anybody knows it?. I understand this could be a heavy constraint. BR, Juanjo.
Re: Problems Implementing a Custom AccessManager
Hi. Thanks for the answers. Is there any date scheduled for the upgrade to Jackrabbit 1.5? ACL was what I was thinking to use, so maybe the upgrade resolves my problem (although I haven't been able to find much documentation on ACL in 1.5 (if someone knows where I can find it I'll appreciate the indication). What worries me the most is that if ACL in 1.5 is not suitable enough for my app, what would be the way to go? On Wed, Dec 17, 2008 at 1:34 AM, Torgeir Veimo torg...@pobox.com wrote: On 17 Dec 2008, at 03:59, Rory Douglas wrote: As for the AccessManager, I think there are plans to upgrade Sling to Jackrabbit 1.5, so it may be more worthwhile to wait for that use the repository-ACL-based AccessManager that comes with 1.5 rather than implementing your own. Or ping me I can send you what I cobbled together for ACL-based control. ACLs are not suitable for most web applications. They're declarative, while most interactive web applications require implicit or application specific security constraints. Sling really needs to allow custom AccessManager implementations. -- Torgeir Veimo torg...@pobox.com
Re: Problems Implementing a Custom AccessManager
Hi Felix. I tested what you told me, but I've seen it's not going to be possible only exporting org.apache.jackrabbit.core.security due to the fact that the AccessManager interface uses org.apache.jackrabbit.core.ItemId (so it will also need org.apache.jackrabbit.core exported, that by what you said I see is not an option). On the other hand I've had a look over the JSR-283 spec and the Jackrabbit 1.5 source code and it looks that it will include exactly what I need, so I think my best option is to hold on until you finish the migration. The thing is that I'm in a bit of a hurry with this part of my application, I've got my deadline quite near, so I hope you don't mind me daring to ask you how much time you estimate it will take (just to know if I can wait, or if I must implement this in some quickdirty way and expect an upgrade in the future). Thanks a lot for your help, and I hope you can help me out with this last doubt. Br, SebatiAn Gomez ;) On Wed, Dec 17, 2008 at 2:44 PM, Felix Meschberger fmesc...@gmail.comwrote: Hi Sebastien, Sebastian Gomez schrieb: Hi. Thanks for the answers. Is there any date scheduled for the upgrade to Jackrabbit 1.5? ACL was what I was thinking to use, so maybe the upgrade resolves my problem (although I haven't been able to find much documentation on ACL in 1.5 (if someone knows where I can find it I'll appreciate the indication). What worries me the most is that if ACL in 1.5 is not suitable enough for my app, what would be the way to go? As Alex said, I am already working on migrating Sling's Jackrabbit inclusion to 1.5. Now for documentation: There is the jackrabbit.apache.org site and there is a Jackrabbit Wiki. If you don't find any documentation there, it is probably best to just ask on the Jackrabbit dev or user list. Finally, since the Jackrabbit access control functionality is an implementation of the JSR-283 (JCR 2.0) access control functionality, you might find the appropriate description there. The public review draft is available from http://www.jcp.org/en/jsr/detail?id=283 Hope this helps. Regards Felix On Wed, Dec 17, 2008 at 1:34 AM, Torgeir Veimo torg...@pobox.com wrote: On 17 Dec 2008, at 03:59, Rory Douglas wrote: As for the AccessManager, I think there are plans to upgrade Sling to Jackrabbit 1.5, so it may be more worthwhile to wait for that use the repository-ACL-based AccessManager that comes with 1.5 rather than implementing your own. Or ping me I can send you what I cobbled together for ACL-based control. ACLs are not suitable for most web applications. They're declarative, while most interactive web applications require implicit or application specific security constraints. Sling really needs to allow custom AccessManager implementations. -- Torgeir Veimo torg...@pobox.com
Problems Implementing a Custom AccessManager
Hi everyone.
I'm trying to secure the JCR repository creating a custom LoginModule and
AccessManager. The first one has gone OK, as it implements the JAAS standard
interface. On the other hand, the second one must implement Jackrabbit's
AccessManager interface, but as Sling's Jackrabbit Embedded Repository
bundle does not export the jackrabbit-core packages (that includes the
AccessManager interface), the only way to create my custom implementation
has been to embed the dependency in my bundle's classpath. This then makes a
ClassCastException occur in Jackrabbit's SessionImpl when my class is being
casted to the AccessManager interface (line 335). As I guess you'll know,
this is because my CustomAccessManager is implementing the AccessManager
loaded by my bundle's classloader, while Jackrabbit's SessionImpl will
expect the AccessManager loaded by the Jackrabbit Embedded Repository
bundle.
I'd like to know if someone has already come up with (and hopefully
resolved) the same problem as I have, because I guess it's quite a common
scenario. The easiest solution would be to make the Sling's Jackrabbit
Embedded Repository bundle to export the security package of jackrabbit-core
but I suppose there must be some reason for it not to be doing so. I'll
appreciate any indication.
Thanks in advance.
Sebastian Gomez.
P.S: Here's the line of org.apache.jackrabbit.core.SessionImpl where the
ClassCastException occurs, marked with a = (in case it's of any use):
protected AccessManager createAccessManager(Subject subject,
HierarchyManager hierMgr)
throws AccessDeniedException, RepositoryException {
AccessManagerConfig amConfig =
rep.getConfig().getAccessManagerConfig();
try {
AMContext ctx = new AMContext(new
File(rep.getConfig().getHomeDir()),
rep.getFileSystem(),
subject,
hierMgr,
rep.getNamespaceRegistry(),
wsp.getName());
AccessManager accessMgr = (AccessManager)
amConfig.newInstance();
accessMgr.init(ctx);
return accessMgr;
} catch (AccessDeniedException ade) {
// re-throw
throw ade;
} catch (Exception e) {
// wrap in RepositoryException
String msg = failed to instantiate AccessManager
implementation: + amConfig.getClassName();
log.error(msg, e);
throw new RepositoryException(msg, e);
}
}
