[weld-dev] Should you allow starting of an external container from mvn test?

[Steven Boscarine]

I like your suggestion of making it a POM option.  I'd advocate that it 
only be started via a specific non-default profile.

For our projects, we usually define projects with non-Maven 
dependencies, like a partner web service or SMTP server, in a specific 
TestNG group which is excluded in the default profile.

Sorry if this is repetitive, but...
The big and central concern that I want to express to people is that you 
can unintentionally trigger code that doesn't belong to your project 
using commands that are typically assumed to be innocuous, like "mvn 
install."

This is a classic scenario where you're giving the developer a really, 
really, really sharp tool.  Individuals obviously need to take 
responsibility for their projects and decide what's appropriate.

For my team (at CHB...my day job), I'd obviously have to make sure that 
they don't put anything where mvn test can run any code that's not part 
of its project.  I'd have no issues with a team member starting an 
embedded container because they would only be running their own code, 
defined in their project, but if someone started up an installed 
container from mvn test, I'd have no choice but to put a stop to it.








On 12/28/2009 02:12 PM, Dan Allen wrote:
> Steven,
>
> 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.
>
> 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.
>
> 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.
>
> -Dan
>
> On Mon, Dec 28, 2009 at 11:13 AM, Steven Boscarine 
> <steven.boscarine at childrens.harvard.edu 
> <mailto:steven.boscarine at childrens.harvard.edu>> wrote:
>
>     Hmm....
>     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...
>
>     Controlling the lifecycle of a non-embedded container from a build
>     is something you want to be very careful about from a security
>     perspective.
>
>     Now, if you have a plugin that requires an explicit command as
>     well as a link in a settings.xml, that seems perfectly reasonable.
>
>     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.
>
>     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.
>
>     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.
>
>
>     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.
>
>     On 12/27/2009 03:54 PM, Dan Allen wrote:
>
>
>>     Awesome, that will be a good feature to get in.
>>
>>     - Dan Allen
>>
>>     Sent from my Android-powered phone:
>>     An open platform for carriers, consumers
>>     and developers.
>>
>>>     On Dec 27, 2009 1:35 PM, "Aslak Knutsen" <aslak at conduct.no
>>>     <mailto:aslak at conduct.no>> wrote:
>>>
>>>     Arquillian 'starts' it, but the container impl does not actually
>>>     start a not started jboss instance.
>>>
>>>     https://jira.jboss.org/jira/browse/ARQ-48
>>>
>>>     -aslak- 2009/12/27 Dan Allen <dan.j.allen at gmail.com
>>>     <mailto:dan.j.allen at gmail.com>> > > +1 on the standalone CDI
>>>     bootstap. I think...
>>>
>>>     -- 
>>>     -- 
>>>
>>>     Aslak Knutsen; +47 952 38 791; fax +47 22 33 60 24
>>>
>>>     Kongens gate 14; Boks 805 Sentrum, 0104 Oslo;
>>>     http://www.conduct.no; mailto:aslak at conduct.no
>>>     <mailto:aslak at conduct.no> Conduc...
>>>
>
>
>
>
> -- 
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
> http://www.google.com/profiles/dan.j.allen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20091228/20789c36/attachment-0001.html