[JBoss JIRA] (ARQ-1010) Support for 'Guest/Nested' Containers
by Aslak Knutsen (JIRA)
Aslak Knutsen created ARQ-1010:
----------------------------------
Summary: Support for 'Guest/Nested' Containers
Key: ARQ-1010
URL: https://issues.jboss.org/browse/ARQ-1010
Project: Arquillian
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Base Implementation, Deployable Containers SPI
Affects Versions: 1.0.1.Final
Reporter: Aslak Knutsen
The current Assumption is that the DeployalbeContainer is the final target. While that works great for ApplicationServers, there are cases where a Service running on the ApplicationServer is one of the Targets.
e.g. a BPM Engine that runs on WLS/WAS/JBossAS etc but has it's own deployment mechanism for deploying the Process definitions.
Currently we would have to create a DeployableContainer impl for each BPM+ContainerX combination to support Managed mode of the Host Container.
In this case the BPM Container should be able to inherit configuration and depend upon the Host Container. e.g. Host runs on IP-X, BPM Container shouldn't need to be reconfigured with the Host IP by the user. When the Host is stopped, the BPM Container should be stopped first.
The interesting usecase is where you have a BPM process that rely on Resources/Services in the Host Contianer. By having them linked you could deploy e.g. WebServices to the Host and Processes to the BPM that interact with the WebServices.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (ARQ-918) Pick a better name for testable attribute on @Deployment annotation
by Dan Allen (JIRA)
Dan Allen created ARQ-918:
-----------------------------
Summary: Pick a better name for testable attribute on @Deployment annotation
Key: ARQ-918
URL: https://issues.jboss.org/browse/ARQ-918
Project: Arquillian
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Base Implementation
Affects Versions: 1.0.0.Final
Reporter: Dan Allen
@Deployment(testable = false) sends the wrong message for a testing platform and is subject to a wide variety of interpretations. We need a better name for this attribute.
The purpose of this attribute is to determine if this deployment should be wrapped up based on the protocol so the test case can be executed inside the container.
I'd be content if we gave it a very explicit name, even if that name wasn't tremendously fluent. Here are some suggestions:
* transportsTest : Indicates whether this deployment will transport the test as part of the deployment so the it can be executed inside the container
* testRunner : Indicates whether this deployment is itself a test runner, which by definition means it will be run inside the container
* providesTestRunner : Mixed mode tests are possible, so this most accurately indicates whether this deployment will provide an additional test runner inside the container
* hostsTest : Indicates whether the deployment will be a host to the test, so the test can be run inside the container
* packageWithTest : Indicates whether this deployment will be packaged with the test and deployed to the server; when false, the deployment is left alone (not packaged with test)
The hard part is that when the test is run in container, the @Deployment archive, the test and the test infrastructure often go into another archive that's the real deployment. So this is more of a directive of how to handle the @Deployment than it is about what role it will serve directly.
I think that "testRunner" or "providesTestRunner" are the most clear options of the ones listed above.
We can support this attribute as an alias to maintain backwards compatibility, marking testable as deprecated.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (ARQ-945) Extract Spring Integration out of Spring Deployer
by Aslak Knutsen (JIRA)
Aslak Knutsen created ARQ-945:
---------------------------------
Summary: Extract Spring Integration out of Spring Deployer
Key: ARQ-945
URL: https://issues.jboss.org/browse/ARQ-945
Project: Arquillian
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Spring Integration
Affects Versions: spring_1.0.0.Alpha1
Reporter: Aslak Knutsen
Assignee: Marius Bogoevici
Fix For: spring_1.0.0.next
In Alpha1 the Service Deployer and the Service Integration is one module, these should be two separate where the Service Integration part can be reused between the Service Deployer and the upcoming Service Container
Service Integration = Enrichers
Service Deployer = Related to moving Spring to a Container (packaging)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months