[
https://issues.apache.org/jira/browse/CAY-2772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrus Adamchik updated CAY-2772:
---------------------------------
Description:
I would like to make our runtime extensions API more user-friendly.
1. Our current module "contribute" API in ServerModule was intended to expose
DI collections to the users for extension. But is still too "technical".
2. Other modules (such as crypto and commitlog) already have extenders similar
to Bootique extenders, but they produce Module instances (while Bootique
extenders have a binder internally, and not building own Module). The Bootique
approach seems less confusing, as service assembly still happens in the main
module, and the extender simply provides building blocks for it.
I would like to unify that into something like this, which seems to be the most
flexible format from Bootique experience:
{noformat}
ServerRuntime
.builder()
.addQueryFilter(MyFilter.class) // cover method for "addModule" with extender
.addModule(b -> ServerModule.extend(b).addQueryFilter(MyFilter.class))
.addModule(b -> CommitLogModule.extend(b).addListener(MyListener.class))
.build();
{noformat}
I am working on a PR now.
was:
I would like to make our runtime extensions API more user-friendly.
1. Our current module "contribute" API in ServerModule was intended to expose
DI collections to the users for extension. But is still too "technical".
2. Other modules (such as crypto and commitlog) already have extenders similar
to Bootique extenders, but they produce Module instances (while Bootique
extenders have a binder internally, and not building own Module). The Bootique
approach seems less confusing, as service assembly still happens in the main
module, and the extender simply provides building blocks for it.
I would like to unify that into something like this, which seems to be the most
flexible format from Bootique experience:
{noformat}
ServerRuntime
.builder()
.addModule(b -> ServerModule.extend(b).addQueryFilter(MyFilter.class))
.addModule(b -> CommitLogModule.extend(b).addListener(MyListener.class))
.build();
{noformat}
FWIW, we can also duplicate all ServerModuleExtender methods in
ServerRuntimeBuilder for shorter configuration.
I am working on a PR now.
> Bootique-style module "extenders" for smoother configuration
> ------------------------------------------------------------
>
> Key: CAY-2772
> URL: https://issues.apache.org/jira/browse/CAY-2772
> Project: Cayenne
> Issue Type: Task
> Reporter: Andrus Adamchik
> Assignee: Andrus Adamchik
> Priority: Major
> Fix For: 5.0.M1
>
>
> I would like to make our runtime extensions API more user-friendly.
> 1. Our current module "contribute" API in ServerModule was intended to expose
> DI collections to the users for extension. But is still too "technical".
> 2. Other modules (such as crypto and commitlog) already have extenders
> similar to Bootique extenders, but they produce Module instances (while
> Bootique extenders have a binder internally, and not building own Module).
> The Bootique approach seems less confusing, as service assembly still happens
> in the main module, and the extender simply provides building blocks for it.
> I would like to unify that into something like this, which seems to be the
> most flexible format from Bootique experience:
> {noformat}
> ServerRuntime
> .builder()
> .addQueryFilter(MyFilter.class) // cover method for "addModule" with
> extender
> .addModule(b -> ServerModule.extend(b).addQueryFilter(MyFilter.class))
> .addModule(b -> CommitLogModule.extend(b).addListener(MyListener.class))
> .build();
> {noformat}
> I am working on a PR now.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
