[arquillian-issues] [JBoss JIRA] (ARQ-2053) Allow Arquillian Core to define a way to execute registration of extensions in order

[Alex Soto (JIRA)]

     [ https://issues.jboss.org/browse/ARQ-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alex Soto updated ARQ-2053:
---------------------------
    Description: 
With Arquillian Extensions you are able to override a service that was previously registered by Arquillian Core or by other extensions. 

The problem is that if if there two extensions that override the same service, it will depend on the order of the registration of the extension that will define which version of the service will be the one used at the end.

To avoid this problem this problem the best way would be to be able to set a priority in extension registry so you can set which one is going to be the last one.

The best none invasive approach we have found is by providing an SPI so any extension can vetoed any service /ResourceProvider/TestEnricher/... to be registered by an extension. This SPI is a file present at META-INF directory and called exclusions. The file is a properties file where key is the service type you want to veto such as (`org.jboss.arquillian.test.spi.enricher.resource.ResourceProvider`) and inside all the implementations you want to veto of this kind, each one separated by comma.

So before starting registering the extensions, the vetoed list will be loaded into service registry so they cannot be registered.

  was:
With Arquillian Extensions you are able to override a service that was previously registered by Arquillian Core or by other extensions. 

The problem is that if if there two extensions that override the same service, it will depend on the order of the registration of the extension that will define which version of the service will be the one used at the end.

To avoid this problem this problem the best way would be to be able to set a priority in extension registry so you can set which one is going to be the last one.

The best none invasive approach we have found is by providing an SPI so any extension can vetoed any service /ResourceProvider/TestEnricher/... to be registered by an extension. This SPI is a file present at META-INF/services directory. The file is named with the service type you want to veto such as (`org.jboss.arquillian.test.spi.enricher.resource.ResourceProvider`) and inside all the implementations you want to veto each one in a new line.

So before starting registering the extensions, the vetoed list will be loaded into service registry so they cannot be registered.



> Allow Arquillian Core to define a way to execute registration of extensions in order
> ------------------------------------------------------------------------------------
>
>                 Key: ARQ-2053
>                 URL: https://issues.jboss.org/browse/ARQ-2053
>             Project: Arquillian
>          Issue Type: Bug
>            Reporter: Alex Soto
>            Priority: Minor
>
> With Arquillian Extensions you are able to override a service that was previously registered by Arquillian Core or by other extensions. 
> The problem is that if if there two extensions that override the same service, it will depend on the order of the registration of the extension that will define which version of the service will be the one used at the end.
> To avoid this problem this problem the best way would be to be able to set a priority in extension registry so you can set which one is going to be the last one.
> The best none invasive approach we have found is by providing an SPI so any extension can vetoed any service /ResourceProvider/TestEnricher/... to be registered by an extension. This SPI is a file present at META-INF directory and called exclusions. The file is a properties file where key is the service type you want to veto such as (`org.jboss.arquillian.test.spi.enricher.resource.ResourceProvider`) and inside all the implementations you want to veto of this kind, each one separated by comma.
> So before starting registering the extensions, the vetoed list will be loaded into service registry so they cannot be registered.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)