[JBoss JIRA] (ARQ-2056) Module Tomcat
by Matous Jobanek (JIRA)
Matous Jobanek created ARQ-2056:
-----------------------------------
Summary: Module Tomcat
Key: ARQ-2056
URL: https://issues.jboss.org/browse/ARQ-2056
Project: Arquillian
Issue Type: Task
Affects Versions: tomcat_1.0.0.CR7
Reporter: Matous Jobanek
Assignee: Matous Jobanek
Fix For: tomcat_1.0.0.CR8
Skip tests for module tomcat-managed-5.5 if JDK 1.8 is used
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ARQ-2054) Update Dependencies
by Hemani Katyal (JIRA)
Hemani Katyal created ARQ-2054:
----------------------------------
Summary: Update Dependencies
Key: ARQ-2054
URL: https://issues.jboss.org/browse/ARQ-2054
Project: Arquillian
Issue Type: Feature Request
Components: Extension - Jacoco
Reporter: Hemani Katyal
Dependencies should be updated to the latest ones:
* Arquilllian Core 1.1.11.Final
* JaCoCo 0.7.7.201606060606
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ARQ-2053) Allow Arquillian Core to define a way to execute registration of extensions in order
by Alex Soto (JIRA)
[ https://issues.jboss.org/browse/ARQ-2053?page=com.atlassian.jira.plugin.s... ]
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)
9 years, 1 month
[JBoss JIRA] (ARQ-2053) Allow Arquillian Core to define a way to execute registration of extensions in order
by Alex Soto (JIRA)
[ https://issues.jboss.org/browse/ARQ-2053?page=com.atlassian.jira.plugin.s... ]
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)
9 years, 1 month
[JBoss JIRA] (ARQ-2053) Allow Arquillian Core to define a way to execute registration of extensions in order
by Alex Soto (JIRA)
Alex Soto created ARQ-2053:
------------------------------
Summary: 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 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.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month