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

Alex Soto (JIRA) issues at jboss.org
Thu Nov 10 09:27:00 EST 2016


     [ 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/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.

  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 using an annotation to set the order where the highest number is the last one to execute. In case of not defining a an annotation, the default order number will be 0.

So as an example an extension could be defined as:

{code:java}
@Precendence(100)
public class MyExtension implements LoadableExtension {}
{code}

The higher value of precedence the sooner it will be registered. This means that to ensure that your extension is registered last, it needs a negative value.



> 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/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.



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


More information about the arquillian-issues mailing list