Re: [VOTE] Release Apache Jackrabbit Oak 0.16
[X] +1 Release this package as Apache Jackrabbit Oak 0.16 Regards, Tommaso 2014-02-06 10:25 GMT+01:00 Alex Parvulescu alexparvule...@apache.org: A candidate for the Jackrabbit Oak 0.16 release is available at: https://dist.apache.org/repos/dist/dev/jackrabbit/oak/0.16/ The release candidate is a zip archive of the sources in: https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-0.16/ The SHA1 checksum of the archive is 54355289b46f5f2fb5c9a19a49e1953bf71025a1. A staged Maven repository is available for review at: https://repository.apache.org/content/repositories/orgapachejackrabbit-1001/ The command for running automated checks against this release candidate is: $ sh check-release.sh oak 0.16 54355289b46f5f2fb5c9a19a49e1953bf71025a1 Please vote on releasing this package as Apache Jackrabbit Oak 0.16. The vote is open for the next 72 hours and passes if a majority of at least three +1 Jackrabbit PMC votes are cast. [ ] +1 Release this package as Apache Jackrabbit Oak 0.16 [ ] -1 Do not release this package because... My vote is +1 best, alex
Re: Make Whiteboard accessible through ContentRepository
On 9.2.14 6:49 , Jukka Zitting wrote: Hi, On Sun, Feb 9, 2014 at 4:05 AM, Davide Giannella giannella.dav...@gmail.com 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. :-) Because this usually works, while starting up an OSGi container and deploying bundles usually results in getting tied up in manual dependency analysis and class loader debugging, which is quite distracting if you just want to run a quick benchmark. Well that, my experience anyway. OTHO I agree that we should probably make an OSGi option available since this is our primary deployment scenario. Michael 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 Mon, Feb 10, 2014 at 1:01 AM, Tobias Bocanegra tri...@apache.org wrote: 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. The same thing works also without OSGi, you just add a new component constructor argument or a setter and adjust the code that does the wiring to provide that dependency to a component. I admit that doing it this way does require changing code in two places, but it also achieves better decoupling of the service from the way it's wired up, i.e. the component itself doesn't have to worry about the mechanics of the service lookup. This simplifies also things like unit test fixtures as you can just mock the direct dependencies of a component instead of setting up a full runtime environment. Declarative Services in OSGi works similarly in decoupling the wiring of services from the services themselves. A DS-based component doesn't necessarily need to access the Component/BundleContext at all, as it can just declare direct dependencies to all the services it needs. Most Oak components should work the same way instead of requiring direct access to the Whiteboard. By making the DS bind methods explicit, you could even write a normal DS-based component that you can also wire up statically in places like oak-run. 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. See above; instead of going through the Whiteboard, I'd rather see a component declaring direct dependencies to the services it needs. The wiring should happen elsewhere. I think my problem is, that there are (were) several instances of the 'DefautlWhiteboard created, one in Oak.java, one by the SecurityProviderImpl. Hmm, I only see a DefaultWhiteboard instance being created in Oak.java. SecurityProviderImpl uses OsgiWhiteboard. Did this change in OAK-1377? 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. We can do that, though one of the driving ideas behind Oak has been to keep things like new Oak().with(new SomeComponent()).createContentSession() as simple as possible. 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. If this becomes a common need, i.e. there are many components that need access to the whiteboard (instead of just a more specific set of services, as suggested above), then I'd rather pull the whiteboard entirely out of the Oak class, like this: Whiteboard whiteboard = ...; new Oak(...) .with(new SecurityProvider(whiteboard)) .createContentRepository(whiteboard); But as said, I think only a small subset of our components should really need direct access to the whiteboard. For example the authorizable action and restriction providers in SecurityProviderImpl are composite services, that in an OSGi deployment can/should be dynamic through the whiteboard mechanism, but in a static deployment shouldn't need the whiteboard as we could just provide a static list of all the available component providers. BR, Jukka Zitting
[RESULT] [VOTE] Release Apache Jackrabbit Oak 0.16
Hi, The vote passes as follows (* marks a binding vote): +1 Alex Parvulescu * +1 Davide Giannella +1 Julian Reschke * +1 Michael Dürig * +1 Tommaso Teofili * Thanks for voting! I'll push the release out, alex On Thu, Feb 6, 2014 at 10:25 AM, Alex Parvulescu alexparvule...@apache.orgwrote: A candidate for the Jackrabbit Oak 0.16 release is available at: https://dist.apache.org/repos/dist/dev/jackrabbit/oak/0.16/ The release candidate is a zip archive of the sources in: https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-0.16/ The SHA1 checksum of the archive is 54355289b46f5f2fb5c9a19a49e1953bf71025a1. A staged Maven repository is available for review at: https://repository.apache.org/content/repositories/orgapachejackrabbit-1001/ The command for running automated checks against this release candidate is: $ sh check-release.sh oak 0.16 54355289b46f5f2fb5c9a19a49e1953bf71025a1 Please vote on releasing this package as Apache Jackrabbit Oak 0.16. The vote is open for the next 72 hours and passes if a majority of at least three +1 Jackrabbit PMC votes are cast. [ ] +1 Release this package as Apache Jackrabbit Oak 0.16 [ ] -1 Do not release this package because... My vote is +1 best, alex
Re: Make Whiteboard accessible through ContentRepository
Hi, On Mon, Feb 10, 2014 at 4:31 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: On Mon, Feb 10, 2014 at 1:01 AM, Tobias Bocanegra tri...@apache.org wrote: 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. The same thing works also without OSGi, you just add a new component constructor argument or a setter and adjust the code that does the wiring to provide that dependency to a component. I admit that doing it this way does require changing code in two places, but it also achieves better decoupling of the service from the way it's wired up, i.e. the component itself doesn't have to worry about the mechanics of the service lookup. This simplifies also things like unit test fixtures as you can just mock the direct dependencies of a component instead of setting up a full runtime environment. in case of the LoginModules, that's not possible. They need to retrieve their services from somewhere. Declarative Services in OSGi works similarly in decoupling the wiring of services from the services themselves. A DS-based component doesn't necessarily need to access the Component/BundleContext at all, as it can just declare direct dependencies to all the services it needs. Most Oak components should work the same way instead of requiring direct access to the Whiteboard. By making the DS bind methods explicit, you could even write a normal DS-based component that you can also wire up statically in places like oak-run. This is ok for unit tests etc, but there is currently no way of configuring Oak. So there is no ootb run.sh that will start your oak server. If we ever want to go there, we need to define how to get there. We can shift this problem to Sling and let them provide such a server, or we can start your own launchpad. currently, you need to compile classes in order to configure your server. if this is ok, we can stay with the current setup and hard-wire all dependencies. 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. See above; instead of going through the Whiteboard, I'd rather see a component declaring direct dependencies to the services it needs. The wiring should happen elsewhere. If you want to make this work generally w/o OSGi, then you also need to invent a DS management for oak...which is clearly not a goal. I think my problem is, that there are (were) several instances of the 'DefautlWhiteboard created, one in Oak.java, one by the SecurityProviderImpl. Hmm, I only see a DefaultWhiteboard instance being created in Oak.java. SecurityProviderImpl uses OsgiWhiteboard. Did this change in OAK-1377? got me :-) I overlooked that. 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. We can do that, though one of the driving ideas behind Oak has been to keep things like new Oak().with(new SomeComponent()).createContentSession() as simple as possible. 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. If this becomes a common need, i.e. there are many components that need access to the whiteboard (instead of just a more specific set of services, as suggested above), then I'd rather pull the whiteboard entirely out of the Oak class, like this: Whiteboard whiteboard = ...; new Oak(...) .with(new SecurityProvider(whiteboard)) .createContentRepository(whiteboard); But as said, I think only a small subset of our components should really need direct access to the whiteboard. The problem is, that the whiteboard that is initially initialized in Oak() already has some anonymous overrides for delaying stuff. So when passing a non-osgi one externally, this logic is lost, although it might be needed. For example the authorizable action and restriction providers in SecurityProviderImpl are composite services, that in an OSGi deployment can/should be dynamic through the whiteboard mechanism, but in a static deployment shouldn't need the whiteboard as we could just provide a static list of all the available component providers. well :-) regards, toby
Re: Make Whiteboard accessible through ContentRepository
Hi, On Mon, Feb 10, 2014 at 2:50 PM, Tobias Bocanegra tri...@apache.org wrote: in case of the LoginModules, that's not possible. But accessing the whiteboard is? I don't see what's special about the whiteboard, it's just a service dependency like any other. This is ok for unit tests etc, but there is currently no way of configuring Oak. So there is no ootb run.sh that will start your oak server. If we ever want to go there, we need to define how to get there. We can shift this problem to Sling and let them provide such a server, or we can start your own launchpad. currently, you need to compile classes in order to configure your server. if this is ok, we can stay with the current setup and hard-wire all dependencies. That is OK, at least that's been the plan so far. It doesn't make sense for Oak to reinvent a component framework like OSGi or Spring. Instead Oak components should be usable within any such framework, or even in plain old Java. The problem is, that the whiteboard that is initially initialized in Oak() already has some anonymous overrides for delaying stuff. So when passing a non-osgi one externally, this logic is lost, although it might be needed. Right. I guess we should refactor that part of the code to avoid the overrides. BR, Jukka Zitting
Re: Slow default methods in abstract classes
Hi, On Thu, Feb 6, 2014 at 4:45 AM, Thomas Mueller muel...@adobe.com wrote: Because we forgot(?) to override those methods, we sometimes ended up with very slow performance. The original purpose of the abstract classes and the generic, unoptimized methods in them was to simplify experimentation and initial implementations when the NodeStore API was being developed. Nowadays they are mostly useful for correct handling of corner cases for which no better/faster implementation is available, but you're right in that it's often too easy to forget that a better implementation is almost always needed for the normal use cases. If a convenience implementation is useful, but slow, it should have a different name, for example equalsBruteForce or AbstractNodeState.compareAgainstBaseStateBruteForce(..). Sounds good. We still do need those methods for the purpose mentioned above, but naming them more explicitly (or having them only as static utility methods like we already do for many AbstractNodeState methods) makes sense. BR, Jukka Zitting
Re: Make Whiteboard accessible through ContentRepository
Hi, On Mon, Feb 10, 2014 at 1:30 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: On Mon, Feb 10, 2014 at 2:50 PM, Tobias Bocanegra tri...@apache.org wrote: in case of the LoginModules, that's not possible. But accessing the whiteboard is? I don't see what's special about the whiteboard, it's just a service dependency like any other. No, it's a piece of infrastructure, and part of the Oak SPI. I think that components should be able to rely on a system wide Whiteboard if they want. Also, the LoginModules are not 'services' in that sense. they get instantiated by JAAS and can only communicate via Callbacks with the login context. This is ok for unit tests etc, but there is currently no way of configuring Oak. So there is no ootb run.sh that will start your oak server. If we ever want to go there, we need to define how to get there. We can shift this problem to Sling and let them provide such a server, or we can start your own launchpad. currently, you need to compile classes in order to configure your server. if this is ok, we can stay with the current setup and hard-wire all dependencies. That is OK, at least that's been the plan so far. It doesn't make sense for Oak to reinvent a component framework like OSGi or Spring. Instead Oak components should be usable within any such framework, or even in plain old Java. The problem is, that the whiteboard that is initially initialized in Oak() already has some anonymous overrides for delaying stuff. So when passing a non-osgi one externally, this logic is lost, although it might be needed. Right. I guess we should refactor that part of the code to avoid the overrides. ok: https://issues.apache.org/jira/browse/OAK-1411 regards, toby
