Re: Make "Whiteboard" accessible through ContentRepository
On Sat, Feb 8, 2014 at 6:58 PM, Tobias Bocanegra wrote: > ... > ps: I still think we should turn the problem around, and make > everything OSGi services and start a small OSGi container for the > runtime :-) I was thinking the same tonight. I was going to ask why (any historical decisions) Oak in the oak-run doesn't use a simple bundled-up OSGi container and runs the related jar, that are already OSGi bundles, in it. It would make for example a lot easier to inject a CommitHook like a custom index. So far the only way to achieve so is to recompile the oak-run adding .with(new MyIndexProvider()) while I'd rather add a Service implementation the OSGi whiteboard. D.
Re: Make "Whiteboard" accessible through ContentRepository
Hi, On Sat, Feb 8, 2014 at 1:58 PM, Tobias Bocanegra wrote: > ok, then what we need it the pendant to the OSGi service registry, [...] s/the pendant/a dependency/? I'm not sure I understood this correctly. > I.e. a mechanism where I can lookup any service. This sounds like an XY problem, i.e. you're proposing a solution without describing the problem you're trying to solve. You mentioned a LoginModule implementation. Why would it need to look up "any" service? Wouldn't a dependency to a specific service be enough/better? > thats what I mean, add the whiteboard from 'Oak.class' to the > constructor to ContentRepositoryImpl. You mean "new ContentRepositoryImpl(..., whiteboard, ...);"? Yes, we can do that. Though as mentioned above I'd like to understand why we need to do that instead of passing the whiteboard (or better, a more specific dependency) directly to whatever component that needs it. > The problem at hand is, that users can provide a service that is used > in one of the login modules. so eventually we need to pass the osgi > whiteboard into the login module. which is easy. but otoh, in the > non-osgi case, a unique whiteboard instance should be passed. which is > not so easy. I don't see the problem: Whiteboard whiteboard = ...; new Oak(...) .with(whiteboard) .with(new SomeComponent(whiteboard)) ; Or perhaps I'm missing something here? > one workaround idea I tested in [0] by introducing "WhiteboardAware" > interface (better name welcome). when such a instance is added to the > Oak instance via a with() method, it oak will push the whiteboard to > it. Right, we can of course do that, but IMHO the above constructor argument pattern seems much simpler. BR, Jukka Zitting
Re: Make "Whiteboard" accessible through ContentRepository
Hi, On Sun, Feb 9, 2014 at 4:05 AM, Davide Giannella wrote: > It would make for example a lot easier to inject a CommitHook like a > custom index. So far the only way to achieve so is to recompile the > oak-run adding .with(new MyIndexProvider()) while I'd rather add a > Service implementation the OSGi whiteboard. Some of us prefer to recompile the jar. :-) Of course that doesn't mean we couldn't do both. If someone's up to it, an OSGi-based runnable Oak jar would be a nice contribution. BR, Jukka Zitting
Re: Make "Whiteboard" accessible through ContentRepository
Hi, On Sun, Feb 9, 2014 at 9:40 AM, Jukka Zitting wrote: > Hi, > > On Sat, Feb 8, 2014 at 1:58 PM, Tobias Bocanegra wrote: >> ok, then what we need it the pendant to the OSGi service registry, [...] > > s/the pendant/a dependency/? I'm not sure I understood this correctly. > >> I.e. a mechanism where I can lookup any service. > > This sounds like an XY problem, i.e. you're proposing a solution > without describing the problem you're trying to solve. ok...using Sling/Felix quite a lot, I'm used to the possibility to create a Service that can have references to any other exported Service via its ComponentContext, i.e. BundleContext, i.e underlying OSGi service registry. > You mentioned a LoginModule implementation. Why would it need to look > up "any" service? Wouldn't a dependency to a specific service be > enough/better? sure, in the end it is a specific service. but we don't want to limit the set of services a login module can use. IMO, it should have access to all the ones registered. So a login module (also in the non osgi world) should be able to retrieve the Whiteboard to get a service. Either directly via a callback (probably the correct solution) or via one of the classes it already can access (ContentRepository or SecurityProvider). >> thats what I mean, add the whiteboard from 'Oak.class' to the >> constructor to ContentRepositoryImpl. > > You mean "new ContentRepositoryImpl(..., whiteboard, ...);"? Yes, we > can do that. Though as mentioned above I'd like to understand why we > need to do that instead of passing the whiteboard (or better, a more > specific dependency) directly to whatever component that needs it. you might be right, it doesn't need it, if the services that needs it is created the correct way. >> The problem at hand is, that users can provide a service that is used >> in one of the login modules. so eventually we need to pass the osgi >> whiteboard into the login module. which is easy. but otoh, in the >> non-osgi case, a unique whiteboard instance should be passed. which is >> not so easy. > > I don't see the problem: > > Whiteboard whiteboard = ...; > new Oak(...) > .with(whiteboard) > .with(new SomeComponent(whiteboard)) > ; > > Or perhaps I'm missing something here? I think my problem is, that there are (were) several instances of the 'DefautlWhiteboard" created, one in Oak.java, one by the SecurityProviderImpl. We should make the DefaultWhiteboard implementation private to Oak. And only allow to create Oak() with or without whiteboard, and remove the Oak.with(Whiteboard) method. So it's clear that either we use the external provided whiteboard, or the implicit internal one. >> one workaround idea I tested in [0] by introducing "WhiteboardAware" >> interface (better name welcome). when such a instance is added to the >> Oak instance via a with() method, it oak will push the whiteboard to >> it. > > Right, we can of course do that, but IMHO the above constructor > argument pattern seems much simpler. the problem is, that each plugin, that needs a whiteboard, should be able to get the default one. without some helper classes, the construction gets a bit awkward: Oak oak = new Oak(); SecurityProvider sp = new SecurityProvider(oak.getWhiteboard()); oak.with(sp); IMO it's better that Oak.with() pushes its whiteboard to the plugin. > > BR, > > Jukka Zitting
Re: Make "Whiteboard" accessible through ContentRepository
On Sun, Feb 9, 2014 at 9:49 AM, Jukka Zitting wrote: > Hi, > > On Sun, Feb 9, 2014 at 4:05 AM, Davide Giannella > wrote: >> It would make for example a lot easier to inject a CommitHook like a >> custom index. So far the only way to achieve so is to recompile the >> oak-run adding .with(new MyIndexProvider()) while I'd rather add a >> Service implementation the OSGi whiteboard. > > Some of us prefer to recompile the jar. :-) > > Of course that doesn't mean we couldn't do both. If someone's up to > it, an OSGi-based runnable Oak jar would be a nice contribution. I played around with the felix runtime and gogo shell in [1] but didn't pursue this further. the problem is, that without a "launchpad" (eg [2]) the bootstrapping is tedious. regards, toby [1] https://github.com/tripodsan/jackrabbit-oak/tree/OAK-17/oak-felix [2] http://sling.apache.org/documentation/the-sling-engine/the-sling-launchpad.html On Sun, Feb 9, 2014 at 9:49 AM, Jukka Zitting wrote: > Hi, > > On Sun, Feb 9, 2014 at 4:05 AM, Davide Giannella > wrote: >> It would make for example a lot easier to inject a CommitHook like a >> custom index. So far the only way to achieve so is to recompile the >> oak-run adding .with(new MyIndexProvider()) while I'd rather add a >> Service implementation the OSGi whiteboard. > > Some of us prefer to recompile the jar. :-) > > Of course that doesn't mean we couldn't do both. If someone's up to > it, an OSGi-based runnable Oak jar would be a nice contribution. > > BR, > > Jukka Zitting
Re: Make "Whiteboard" accessible through ContentRepository
Hi This thread indeed raises the question, why Oak has to come up with something (the Whiteboard) that is almost but not quite like OSGi instead of going all the way through ? As a stop-gap measure, instead of going full-OSGi you could also just leverage the feature, that you really need: The service registry and base on something like Karl Pauls' µServices [2] and PojoSR [3] Interestingly, when I started with what became Apache Sling I worked on a thing called the "Extension Frameworkg for JCR Repositories" [1] until it turned out that it basically would be reinventing OSGi … and so Sling became an OSGi application. Regards Felix [1] http://svn.apache.org/repos/asf/jackrabbit/sandbox/inactive/extension-framework/ [2] http://www.pro-vision.de/content/medialib/pro-vision/production/adaptto/2013/adaptto2013-osgi--services-karl-pauls-pdf/_jcr_content/renditions/rendition.download_attachment.file/adaptto2013-osgi--services-karl-pauls.pdf [3] http://code.google.com/p/pojosr/ Am 09.02.2014 um 10:05 schrieb Davide Giannella : > On Sat, Feb 8, 2014 at 6:58 PM, Tobias Bocanegra wrote: >> ... >> ps: I still think we should turn the problem around, and make >> everything OSGi services and start a small OSGi container for the >> runtime :-) > > I was thinking the same tonight. I was going to ask why (any > historical decisions) Oak in the oak-run doesn't use a simple > bundled-up OSGi container and runs the related jar, that are already > OSGi bundles, in it. > > It would make for example a lot easier to inject a CommitHook like a > custom index. So far the only way to achieve so is to recompile the > oak-run adding .with(new MyIndexProvider()) while I'd rather add a > Service implementation the OSGi whiteboard. > > D.
