Mailing-List: contact dev-help@polygene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@polygene.apache.org
Date: Fri, 26 May 2017 14:57:04 +0000 (UTC)
From: "Paul Merlin (JIRA)" <jira@apache.org>
To: dev@polygene.apache.org
Message-ID: <JIRA.13073941.1495474354000.303136.1495810624117@Atlassian.JIRA>
In-Reply-To: <JIRA.13073941.1495474354000@Atlassian.JIRA>
References: <JIRA.13073941.1495474354000@Atlassian.JIRA> <JIRA.13073941.1495474354217@jira-lw-us.apache.org>
Subject: [jira] [Commented] (POLYGENE-257) Custom IdentityGenerator or
 Serialization hidden by default assemblers
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Fri, 26 May 2017 14:57:08 -0000


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

Paul Merlin commented on POLYGENE-257:
--------------------------------------

Yeah, the added magic layer is not a nice solution. Or it would need to be read-only and hidden. Which sounds very ad-hoc.

I agree we should remove both IdentityGenerator and Serialization from defaultAssemblers.

But I think we need to provide some convenience for both tests and applications assemblies. It basically should be an opt-in. For AbstractPolygeneTest it could be enabled by default with a way to opt-out.

I also think we should have "default services", but no "fallbacks", and treat MetricsProvider the same way. So that the service semantics can apply directly.

For both applications and non-trivial tests one will want to opt-in on a given Layer/Module. Moreover, one may want the default IdentityGenerator but not the default Serialization etc...

Here are a few assembly api proposals:
{code}
// on the ModuleAssembly:
moduleAssembly.defaultServices()
        .visibleIn( Visibility.application );
// for each "default service":
moduleAssembly.defaultIdentityGenerator()
        .visibleIn( Visibility.application );
moduleAssembly.defaultSerialization()
        .visibleIn( Visibility.application );
moduleAssembly.defaultMetricsProvider()
        .visibleIn( Visibility.application );
{code}

These would return a classic `ServiceDeclaration`. It'd be easily usable with SingletonAssembler, tests etc.. while providing fine grained control for non trivial assemblies.

On a side note, ideally, service lookup exceptions should guide the user towards resolving her assembly errors. For now they only say, not found, here are the ones that you could have found. That's not very useful. For injections, knowing what required a service without having to "decypher" the stacktrace would be way better.


> Custom IdentityGenerator or Serialization hidden by default assemblers
> ----------------------------------------------------------------------
>
>                 Key: POLYGENE-257
>                 URL: https://issues.apache.org/jira/browse/POLYGENE-257
>             Project: Polygene
>          Issue Type: Bug
>            Reporter: Paul Merlin
>            Assignee: Paul Merlin
>             Fix For: 3.0.0
>
>
> See https://lists.apache.org/thread.html/9b28a67e75cb8952202d0b0b029de53fc19257b733907408ba20ccde@%3Cdev.polygene.apache.org%3E


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)