Steven,<br><br>Naturally, starting and stopping the container from a test is going to be a preference that some developers will want and others not. That's why I suggested that it would be a system property (or some other configuration mechanism) that you could use to enable this behavior. I can tell you that from experience working with the CDI TCK that this was a very nice feature to have. I'm sure the other guys that worked on the TCK could offer their opinion.<br>
<br>The subject line of your e-mail made me thinking of another possibility. It would be possible to include a Maven plugin configuration that would start and stop the container around the test (or integration) phase of the Maven life cycle. The only downside there is that it wouldn't carry over to the IDE JUnit or TestNG plugin.<br>
<br>So, in general, I think it's a good thing to offer. I also agree that it shouldn't be the only way, perhaps not even the default behavior.<br><br>-Dan<br><br><div class="gmail_quote">On Mon, Dec 28, 2009 at 11:13 AM, Steven Boscarine <span dir="ltr"><<a href="mailto:steven.boscarine@childrens.harvard.edu">steven.boscarine@childrens.harvard.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div text="#000000" bgcolor="#ffffff">
Hmm....<br>
Sorry to come to the conversation late on this, but this e-mail is
raising a potential red flag for me. I apologize if this has been
already addressed and I missed it, but...<br>
<br>
Controlling the lifecycle of a non-embedded container from a build is
something you want to be very careful about from a security
perspective. <br>
<br>
Now, if you have a plugin that requires an explicit command as well as
a link in a settings.xml, that seems perfectly reasonable. <br>
<br>
I am worried that a someone running "mvn test" for application foo.war
could startup non-foo wars because they were deployed to a local
container. <br>
<br>
Also, I am concerned that it may startup the wrong container and cause
similar problems. I usually work on multiple applications at a time
and have a container for foo.war and a separate container for bar.war.
I may think it is starting up foo's container, but it may startup bar's
container and cause trouble. <br>
<br>
For me, that can get really dangerous because my applications contact
external resources on startup as well as access things like files and
bdb databases that are not suitable for usage by multiple
applications. They could corrupt the file with simultaneous writes or
more likely write duplicate or erroneous data.<br>
<br>
<br>
I know I sound like a member of the "tin-foil-hat-club" here, but I
deal with patient data, so my apps are required by law to be paranoid
about security. <br>
<br>
On 12/27/2009 03:54 PM, Dan Allen wrote:<br>
<br>
<br>
<blockquote type="cite">
<p>Awesome, that will be a good feature to get in. </p>
<p>- Dan Allen</p>
<p>Sent from my Android-powered phone:<br>
An open platform for carriers, consumers<br>
and developers.</p>
<blockquote type="cite">On Dec 27, 2009 1:35 PM, "Aslak Knutsen" <<a href="mailto:aslak@conduct.no" target="_blank">aslak@conduct.no</a>>
wrote:<br>
<br>
Arquillian 'starts' it, but the container impl does not actually start
a not started jboss instance.
<div><br>
</div>
<div><a href="https://jira.jboss.org/jira/browse/ARQ-48" target="_blank">https://jira.jboss.org/jira/browse/ARQ-48</a></div>
<div><br>
</div>
<div>
<p><font color="#500050">-aslak-
2009/12/27 Dan Allen <<a href="mailto:dan.j.allen@gmail.com" target="_blank">dan.j.allen@gmail.com</a>>
>
> +1 on the standalone CDI bootstap. I think...</font></p>
-- <br>
--
<p><font color="#500050">Aslak Knutsen; +47 952 38 791; fax +47 22
33 60 24
</font></p>
<p><font color="#500050">Kongens gate 14; Boks 805 Sentrum, 0104
Oslo;
<a href="http://www.conduct.no" target="_blank">http://www.conduct.no</a>;
mailto:<a href="mailto:aslak@conduct.no" target="_blank">aslak@conduct.no</a>
Conduc...</font></p>
</div>
</blockquote>
</blockquote>
<br>
</div>
</blockquote></div><br><br clear="all"><br>-- <br>Dan Allen<br>Senior Software Engineer, Red Hat | Author of Seam in Action<br>Registered Linux User #231597<br><br><a href="http://mojavelinux.com">http://mojavelinux.com</a><br>
<a href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a><br><a href="http://www.google.com/profiles/dan.j.allen">http://www.google.com/profiles/dan.j.allen</a><br>