You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Jukka Zitting <ju...@gmail.com> on 2012/10/19 17:25:42 UTC
Repository construction
Hi,
As you may have noticed from my work in OAK-352, we now have pretty
clean and simple mechanism for constructing repositories with
different combinations of pluggable components. Here's a quick guide
on how to use this mechanism.
The core class to use is called Oak and can be found in the
org.apache.jackrabbit.oak package inside oak-core. It takes a
MicroKernel instance and wraps it into a ContentRepository:
MicroKernel kernel = ...;
ContentRepository repository = new Oak(kernel).createContentRepository();
For test purposes you can use the default constructor that
automatically instantiates an in-memory MicroKernel for use with the
repository. And if you're only using the test repository for a single
ContentSession or just a singe Root, then you can shortcut the login
steps by using either of the last two statements below:
ContentRepository repository = new Oak().createContentRepository();
ContentSession session = new Oak().createContentSession();
Root root = new Oak().createRoot();
By default no pluggable components are associated with the created
repository, so all login attempts will work and result in full write
access. There's also no need to close the sessions or otherwise
release acquired resources, as normal garbage collection will take
care of everything.
To add extra functionality like type validation or indexing support,
use the with() method. The method takes all kinds of Oak plugins and
adds them to the repository to be created. The method returns the Oak
instance being used, so you can chain method calls like this:
ContentRepository repository = new Oak(kernel)
.with(new InitialContent()) // add initial content
.with(new DefaultTypeEditor()) // automatically set default types
.with(new NameValidatorProvider()) // allow only valid JCR names
.with(new SecurityProviderImpl()) // use the default security
.with(new PropertyIndexHook()) // simple indexing support
.with(new PropertyIndexProvider()) // search support for the indexes
.createContentRepository();
As you can see, constructing a fully featured JCR repository like this
will require quite a few plugins. To avoid having to specify them all
whenever constructing a new repository, we also have a class called
Jcr in the org.apache.jakcrabbit.oak.jcr package in oak-jcr. That
class works much like the Oak class, but it constructs
javax.jcr.Repository instances instead of ContentRepositories and
automatically includes all the plugin components needed for proper JCR
functionality.
MicroKernel kernel = ...;
Repository repository = new Jcr(kernel).createRepository();
The Jcr class supports all the same with() methods as the Oak class
does, so you can easily extend the constructed JCR repository with
custom functionality if you like. For test purposes the Jcr class also
has an empty default constructor that works like the one in the Oak
class.
Note that this mechanism is mostly intended for embedded use.
Deployments in OSGi and other managed environments should use the
native construction/configuration mechanism of the environment.
BR,
Jukka Zitting
Re: Repository construction
Posted by Stefan Guggisberg <st...@gmail.com>.
On Fri, Oct 19, 2012 at 5:25 PM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> As you may have noticed from my work in OAK-352, we now have pretty
> clean and simple mechanism for constructing repositories with
> different combinations of pluggable components. Here's a quick guide
> on how to use this mechanism.
>
> The core class to use is called Oak and can be found in the
> org.apache.jackrabbit.oak package inside oak-core. It takes a
> MicroKernel instance and wraps it into a ContentRepository:
>
> MicroKernel kernel = ...;
> ContentRepository repository = new Oak(kernel).createContentRepository();
>
> For test purposes you can use the default constructor that
> automatically instantiates an in-memory MicroKernel for use with the
> repository. And if you're only using the test repository for a single
> ContentSession or just a singe Root, then you can shortcut the login
> steps by using either of the last two statements below:
>
> ContentRepository repository = new Oak().createContentRepository();
> ContentSession session = new Oak().createContentSession();
> Root root = new Oak().createRoot();
>
> By default no pluggable components are associated with the created
> repository, so all login attempts will work and result in full write
> access. There's also no need to close the sessions or otherwise
> release acquired resources, as normal garbage collection will take
> care of everything.
>
> To add extra functionality like type validation or indexing support,
> use the with() method. The method takes all kinds of Oak plugins and
> adds them to the repository to be created. The method returns the Oak
> instance being used, so you can chain method calls like this:
>
> ContentRepository repository = new Oak(kernel)
> .with(new InitialContent()) // add initial content
> .with(new DefaultTypeEditor()) // automatically set default types
> .with(new NameValidatorProvider()) // allow only valid JCR names
> .with(new SecurityProviderImpl()) // use the default security
> .with(new PropertyIndexHook()) // simple indexing support
> .with(new PropertyIndexProvider()) // search support for the indexes
> .createContentRepository();
>
> As you can see, constructing a fully featured JCR repository like this
> will require quite a few plugins. To avoid having to specify them all
> whenever constructing a new repository, we also have a class called
> Jcr in the org.apache.jakcrabbit.oak.jcr package in oak-jcr. That
> class works much like the Oak class, but it constructs
> javax.jcr.Repository instances instead of ContentRepositories and
> automatically includes all the plugin components needed for proper JCR
> functionality.
>
> MicroKernel kernel = ...;
> Repository repository = new Jcr(kernel).createRepository();
>
> The Jcr class supports all the same with() methods as the Oak class
> does, so you can easily extend the constructed JCR repository with
> custom functionality if you like. For test purposes the Jcr class also
> has an empty default constructor that works like the one in the Oak
> class.
nice!
cheers
stefan
>
> Note that this mechanism is mostly intended for embedded use.
> Deployments in OSGi and other managed environments should use the
> native construction/configuration mechanism of the environment.
>
> BR,
>
> Jukka Zitting
Re: Repository construction
Posted by Chetan Mehrotra <ch...@gmail.com>.
Hi Angela,
> the security provider is IMO just a temporary solution
> in order to have a quick way to setup the system. there will
> for sure be major refactoring in terms of configuration, initial
> content, commit hooks, validation and so forth...
> i don't see to much benefit in putting a lot of effort in this
> right now
I wanted to use the new configuration support in SecurityProvider to
customize the user and group home paths (as I have them hardcoded in
my fork). So for now I would create the SecurityProvider instance
directly -> configure it -> pass it to ContentRepositoryImpl.
regards
Chetan
Re: Repository construction
Posted by Angela Schreiber <an...@adobe.com>.
hi chetan
> 3. SecurityProvider - Need to register SecurityProviderImpl backed by
> OSGi configuration with SR. Would it be fine now to add osgi related
> changes
the security provider is IMO just a temporary solution
in order to have a quick way to setup the system. there will
for sure be major refactoring in terms of configuration, initial
content, commit hooks, validation and so forth...
i don't see to much benefit in putting a lot of effort in this
right now.
regards
angela
Re: Repository construction
Posted by Chetan Mehrotra <ch...@gmail.com>.
On Fri, Oct 19, 2012 at 8:55 PM, Jukka Zitting <ju...@gmail.com> wrote:
> Note that this mechanism is mostly intended for embedded use.
> Deployments in OSGi and other managed environments should use the
> native construction/configuration mechanism of the environment.
I was trying to modify the Oak usage in OSGi environment to match the
settings similar to what is done in default o.a.j.oak.jcr.Jcr class.
To achieve the compatibility I need to resolve couple of issues
1. Lucene and OSGi - To enable Lucene related logic some steps are required
(A) Wrap up the Lucene jars as OSGi bundle - The current released
versions of Lucene 4.0.0 are not OSGi bundles. Some discussion around
it happened in LUCENE-3167 but looks like it did not got resolved. So
should we create our own wrapper bundle in Oak for now?
(B) Registration of Lucene related components -
LuceneReindexHook,LuceneHook and LuceneIndexProvider with OSGi SR
such that they can be picked up by the o.a.j.oak.osgi.Activator and
registered with the ContentRepository being constructed. We can have a
single Lucene component which uses OSGi configuration to configure
Lucene related logic (for now its only the homePath) and registers the
respective components in SR
2. Commit Hooks - Should we add a tracker for CommitHooks similar to
the way we have ones for ValidatorProvider and IndexProviders. Or for
now we can just update the list present in the
o.a.j.oak.osgi.Activator to match the list and order we have in
o.a.j.oak.jcr.Jcr
3. SecurityProvider - Need to register SecurityProviderImpl backed by
OSGi configuration with SR. Would it be fine now to add osgi related
changes
Chetan Mehrotra
Re: Repository construction
Posted by Michael Dürig <md...@apache.org>.
Hi Jukka,
Thanks for sharing this, good stuff! I think this write up would best go
into another .md file in /doc. WDYT?
Michael
On 19.10.12 16:25, Jukka Zitting wrote:
> Hi,
>
> As you may have noticed from my work in OAK-352, we now have pretty
> clean and simple mechanism for constructing repositories with
> different combinations of pluggable components. Here's a quick guide
> on how to use this mechanism.
>
> The core class to use is called Oak and can be found in the
> org.apache.jackrabbit.oak package inside oak-core. It takes a
> MicroKernel instance and wraps it into a ContentRepository:
>
> MicroKernel kernel = ...;
> ContentRepository repository = new Oak(kernel).createContentRepository();
>
> For test purposes you can use the default constructor that
> automatically instantiates an in-memory MicroKernel for use with the
> repository. And if you're only using the test repository for a single
> ContentSession or just a singe Root, then you can shortcut the login
> steps by using either of the last two statements below:
>
> ContentRepository repository = new Oak().createContentRepository();
> ContentSession session = new Oak().createContentSession();
> Root root = new Oak().createRoot();
>
> By default no pluggable components are associated with the created
> repository, so all login attempts will work and result in full write
> access. There's also no need to close the sessions or otherwise
> release acquired resources, as normal garbage collection will take
> care of everything.
>
> To add extra functionality like type validation or indexing support,
> use the with() method. The method takes all kinds of Oak plugins and
> adds them to the repository to be created. The method returns the Oak
> instance being used, so you can chain method calls like this:
>
> ContentRepository repository = new Oak(kernel)
> .with(new InitialContent()) // add initial content
> .with(new DefaultTypeEditor()) // automatically set default types
> .with(new NameValidatorProvider()) // allow only valid JCR names
> .with(new SecurityProviderImpl()) // use the default security
> .with(new PropertyIndexHook()) // simple indexing support
> .with(new PropertyIndexProvider()) // search support for the indexes
> .createContentRepository();
>
> As you can see, constructing a fully featured JCR repository like this
> will require quite a few plugins. To avoid having to specify them all
> whenever constructing a new repository, we also have a class called
> Jcr in the org.apache.jakcrabbit.oak.jcr package in oak-jcr. That
> class works much like the Oak class, but it constructs
> javax.jcr.Repository instances instead of ContentRepositories and
> automatically includes all the plugin components needed for proper JCR
> functionality.
>
> MicroKernel kernel = ...;
> Repository repository = new Jcr(kernel).createRepository();
>
> The Jcr class supports all the same with() methods as the Oak class
> does, so you can easily extend the constructed JCR repository with
> custom functionality if you like. For test purposes the Jcr class also
> has an empty default constructor that works like the one in the Oak
> class.
>
> Note that this mechanism is mostly intended for embedded use.
> Deployments in OSGi and other managed environments should use the
> native construction/configuration mechanism of the environment.
>
> BR,
>
> Jukka Zitting
>