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:
Thank you for reply. I also asked myself these three questions. I think flag autoStartup=false (with default "true" value) should be applied to each binding for flexible customization. But also services should have disableBindingsAutoStartup flag which overrides similar flag for bindings in case of large number of bindings. For reference bindings this flag does not make sense, because any exchange to reference binding will automatically wake up his Camel route.
Currently I have necessary changes in switchyard-core deploy module and switchyard-component-common-camel module. I just have to make changes in XSD-schemas for switchyard maven validation plugin and create appropriate unit tests.
Will wait your JIRA issue.
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.
Oh, I'm sorry. I misread the phrase "here's what I would do" as "I will do" .
Ok, I will test this feature on domain level also and prepare JIRA request and PR on weekends.
Thank you for explanation.
I have created the issue and sent 2 PR.
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,...).
Yes, I have tested it. It works well. So now I manage bindings lifecycle via MBeanServer by your earlier recommendations without any problems. I have faced with one issue described here: Re: Programmatically getting SwitchYardCamelContext or ServiceDomain instances . But it can be easily solved by first comment on the issue page.