This could be an interesting enhancement.  Some considerations:

• Do you need this flag on each service or would it be better as a domain property (i.e. application-wide) instead?
• If you need service-level granularity, does it apply to an entire service or just a specific binding on that service?
• Is there any reason why this should apply to reference bindings?  I can't see how this would be useful at this stage.

In terms of making a contribution, here's what I would do:

• File a JIRA requesting the enhancement.
• Issue a PR for the repositories impacted by your change.
• Note the PR in the issue and post back to the forum for comments.

This might help as well:

Development on SwitchYard

Pavel,

I think Keith is suggesting that you go ahead and file the JIRA yourself - you are essentially creating the feature, so you know the requirements best.   The JIRA report doesn't have to be super detailed, but if you can summarize what you said here and link to the discussion thread here, that'd be very useful.

The one thing I would note is that if you're already adding this feature at the binding level and the service level, it probably also makes sense to add it at the domain level like Keith suggests.

--Tom

Hi Pavel,

This is your JIRA ([SWITCHYARD-2580] Make it possible to don't startup service bindings automatically - JBoss Issue Tracker) for others reference.

I now I'm facing a similar requirement, in that I need to do an upgrade of my application (a very big application) and I want it to be deployed on stopped mode, so everything is properly deployed before starting the bindings (to do a proper software upgrade as a rolling update). We're using SOAP, JMS, SCA (non-clustered), Quartz, FTP,... and we don't want to start things up before everything gets properly deployed, as it will generate many errors.

Have you tested your PR? Is it working fine? What issues have you found?

I have voted to incorporate it into next release, as this is a very interesting feature to be able to update systems in production.

And yes, we are not using clustered SCA (don't really like how it works on SY 1.1 as it uses HTTP transport always) and we can't use mod_cluster for doing a rolling upgrade as we have many bindings that would start consumption as they are not HTTP based and not balanced with mod_cluster (like timers, file/ftp, jms,...).