[JBoss JIRA] (ARQ-1302) Support Weld 2.x
by Aslak Knutsen (JIRA)
Aslak Knutsen created ARQ-1302:
----------------------------------
Summary: Support Weld 2.x
Key: ARQ-1302
URL: https://issues.jboss.org/browse/ARQ-1302
Project: Arquillian
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Weld Containers
Affects Versions: weld_1.0.0.CR5
Reporter: Aslak Knutsen
Assignee: Aslak Knutsen
Fix For: weld_1.0.0.Final
ARQ-1168 Added a tight dependency on the BeansXml API from Weld Bootstrap SPI. This SPI has changed in the Weld 2.x branch which cause the Container to fail runtime.
The reason for the tight dependency is to support merging duplicate entries in beans.xml when using a FlatDeployment structure.
Weld 2.x Bootstrap has added support for this feature via the new parse(beans.xml, merge) method.
Update the weld containers to support the old and new way of merging the beans.xml.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (ARQ-1027) Support CommandService Protocol SPI via Warp Protocol
by Aslak Knutsen (JIRA)
[ https://issues.jboss.org/browse/ARQ-1027?page=com.atlassian.jira.plugin.s... ]
Aslak Knutsen commented on ARQ-1027:
------------------------------------
sorry about that.. approved :)
> Support CommandService Protocol SPI via Warp Protocol
> -----------------------------------------------------
>
> Key: ARQ-1027
> URL: https://issues.jboss.org/browse/ARQ-1027
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Affects Versions: warp_1.0.0.Alpha1
> Reporter: Curtis McMillen
> Priority: Critical
> Fix For: warp_1.0.0.Beta1
>
> Attachments: stacktrace.txt
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> It seems there is a problem with running Warp tests if arquillian-jacoco is on the classpath.
> When WarpFilter fires the AfterSuite event, the writeCoverageData observer in arquillian-jacoco is executing which ultimately leads to a NPE coming from servlet protocol. The full stacktrace is attached.
> You can reproduce by simply adding the following dependencies to the pom for warp in arquillian-showcase and then running the BasicJSFUnitTestCase.
> {code:xml}
> <dependency>
> <groupId>org.jboss.arquillian.extension</groupId>
> <artifactId>arquillian-jacoco</artifactId>
> <version>1.0.0.Alpha3</version>
> <scope>test</scope>
> </dependency>
> <dependency>
> <groupId>org.jacoco</groupId>
> <artifactId>org.jacoco.core</artifactId>
> <version>0.5.7.201204190339</version>
> <scope>test</scope>
> </dependency>
> {code}
> Removing these dependencies isn't really an option because I have other arquillian tests not using Warp that I want code coverage on. I tried using alternative annotated with @Specializes thinking I could basically disable the observer in arquillian-jacoco simply by including a different beans.xml in the deployment of my Warp tests. This however fails with "WELD-000047 Specializing bean must extend another bean" which I'm thinking is due to https://issues.jboss.org/browse/WELD-1113.
> Any ideas for getting this to work?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (ARQ-1027) Support CommandService Protocol SPI via Warp Protocol
by Aris Tzoumas (JIRA)
[ https://issues.jboss.org/browse/ARQ-1027?page=com.atlassian.jira.plugin.s... ]
Aris Tzoumas commented on ARQ-1027:
-----------------------------------
Bump...
The CLA is still in status "Awaiting approval by project lead"
> Support CommandService Protocol SPI via Warp Protocol
> -----------------------------------------------------
>
> Key: ARQ-1027
> URL: https://issues.jboss.org/browse/ARQ-1027
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Affects Versions: warp_1.0.0.Alpha1
> Reporter: Curtis McMillen
> Priority: Critical
> Fix For: warp_1.0.0.Beta1
>
> Attachments: stacktrace.txt
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> It seems there is a problem with running Warp tests if arquillian-jacoco is on the classpath.
> When WarpFilter fires the AfterSuite event, the writeCoverageData observer in arquillian-jacoco is executing which ultimately leads to a NPE coming from servlet protocol. The full stacktrace is attached.
> You can reproduce by simply adding the following dependencies to the pom for warp in arquillian-showcase and then running the BasicJSFUnitTestCase.
> {code:xml}
> <dependency>
> <groupId>org.jboss.arquillian.extension</groupId>
> <artifactId>arquillian-jacoco</artifactId>
> <version>1.0.0.Alpha3</version>
> <scope>test</scope>
> </dependency>
> <dependency>
> <groupId>org.jacoco</groupId>
> <artifactId>org.jacoco.core</artifactId>
> <version>0.5.7.201204190339</version>
> <scope>test</scope>
> </dependency>
> {code}
> Removing these dependencies isn't really an option because I have other arquillian tests not using Warp that I want code coverage on. I tried using alternative annotated with @Specializes thinking I could basically disable the observer in arquillian-jacoco simply by including a different beans.xml in the deployment of my Warp tests. This however fails with "WELD-000047 Specializing bean must extend another bean" which I'm thinking is due to https://issues.jboss.org/browse/WELD-1113.
> Any ideas for getting this to work?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (ARQ-1301) JAR Deployment on managed GlassFish throws NullPonterException
by Dirk Weil (JIRA)
Dirk Weil created ARQ-1301:
------------------------------
Summary: JAR Deployment on managed GlassFish throws NullPonterException
Key: ARQ-1301
URL: https://issues.jboss.org/browse/ARQ-1301
Project: Arquillian
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: GlassFish Containers
Affects Versions: 1.0.0.CR3
Environment: Windows 7
Reporter: Dirk Weil
Deployment of an EJB JAR failes with a NullPointerException in org.jboss.arquillian.container.glassfish.clientutils.GlassFishClientService.doDeploy.
The issue can be reproduced by a deployment like this:
@Deployment(testable = false)
public static Archive<?> createDeployment()
{
JavaArchive archive = ShrinkWrap.create(JavaArchive.class, "foo.jar");
archive.addClasses(UserInfoBean.class, UserInfo.class);
return archive;
}
The classes UserInfoBean and UserInfo define a simple stateless bean, but that is not important here: The NullPointerException is thrown regardless of the actual contents of the deployed jar file.
Obviously subComponents is assigned null in doDeploy (line 219):
Map<String, String> subComponents = (Map<String, String>) subComponentsResponce.get("properties");
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months