polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niclas Hedhman (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (POLYGENE-279) Custom @Structure injection types
Date Sun, 03 Dec 2017 03:31:00 GMT

    [ https://issues.apache.org/jira/browse/POLYGENE-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16275813#comment-16275813

Niclas Hedhman commented on POLYGENE-279:

Further experiment; Putting StructureComposites in the ApplicationModel is not viable. Too
much of Core Runtime expects a valid Module in Composites, and having checks for this special
case is not viable. One gets quite far in implementation, when it all come crushing down.

Possible Part of Solution; We could simply demand that StructureComposites are placed into
regular modules, and handled the normal way. with a
StructureDeclaration structures( Class<?> structureType );
in ModuleAssembly, just like other composite meta types.

Possible Part of Solution; Maybe StructureComposite as an actual composite meta type is not
needed, and we can simply use regular Transients.

Possible Part of Solution; we could introduce an "all" visibility, which makes the type visible
throughout the application. It should have been "application" visibility, but that one is
taken. With that, the default structures are simply placed into a default module, typically
in an Infrastructure or similar layer. 

Possible Part of Solution; we could make a layer with visibility "none", that is only visible
to structure injection mechanism. Such layer could be implicit, but reachable during assembly
under a given/magic name, and have N modules for different purposes.

> Custom @Structure injection types
> ---------------------------------
>                 Key: POLYGENE-279
>                 URL: https://issues.apache.org/jira/browse/POLYGENE-279
>             Project: Polygene
>          Issue Type: New Feature
>            Reporter: Niclas Hedhman
> Use-case 1; UnitOfWorkFactory is currently depending on a UnitOfWorkFactory declaration
in every module where one need it injected, or otherwise one risk having the wrong visibility
established. The current behavior is a design flaw, not present in earlier Qi4j versions.
> Use-case 2; MetricsProvider should be able to create module-specific (or module-aware)
Metric instances, without having to be declared in every module where metrics are needed.
> Use-case 3; IdentityManager should be allowed to generate IDs that use module names,
without being declared in every module.
> Currently, we don't have any particular types that deal with @Structure injections, nothing
that holds the additional information needed. But there is a need to be both a singleton,
i.e. a Service as well as a unique object that is injected into the target composite.

This message was sent by Atlassian JIRA

View raw message