SwitchYard bean service lifecycle handlers

[synclpz]

Hello,

I'm currently evaluating SwitchYard and trying to implement some custom services via beans that need to be somehow "started" and "stopped" - because they actually implement connectors to remote system via proprietary protocol. Also they need to be configured via some conf file (properties, or anything, e.g. external system IP:port).

So, the questions are:

1. Am I doing it right way implementing connectors to remote systems as bean services?

2. Is there any possibility to have something like lifecycle-listener for bean (or other) service? For example, create class MyLyfeCycleListsner implements (whatever)LifecycleListener { public void onStateChange(State state) {..}} and wire it up somehow with SwitchYard service?

3. At the moment I'm trying to implement this approach via bean constructor, but Context and @Property(name="any") are not available outside of service implementation method, so I probably will end up with using some custom XML conf files... Using constructor is not the good way also, because I cannot place some logic to "stop" the service (I don't know when SY stops my bean service, for example for re-deployment with new config).

Does anyone have suggestions what is wrong with this all stuff and how to do it right?

[kcbabo]

Gateways expose a user-managed lifecycle in SwitchYard, implementation components do not.  For this use case, I would create a Camel component and then configure it via it's URI.   There will be documentation on how to add extension Camel components in the 1.0 docset.

[synclpz]

It's a pity that components cannot react to lifecycle state change. Do you intentionally not incorporating this functionality into SY?

Concerning Camel - I'm not (yet) familiar with that technology, but I'll try

Can you point me to the right place to start with gateway and it's lifecycle implementation? Some docs/source/package maybe?

At the moment I given up with putting custom xml-file to classpath and parsing config in in @PostConstruct bean method, then free all resources in @PreDestroy one. I think it should also work...

PS: When do you suppose to release SY1.0?

[synclpz]

Addition to this:

At the moment I given up with putting custom xml-file to classpath and parsing config in in @PostConstruct bean method, then free all resources in @PreDestroy one. I think it should also work...

@PreDestroy is never called. So, really no way to tear down communication channels and stop threads.

[kcbabo]

SwitchYard 1.0 will be released this month.

@PreDestroy is invoked as part of the lifecycle of a managed bean by CDI, so if @PreDestroy is not being called it may ben an issue with

I would not implement a gateway to external systems using an implementation in SwitchYard, that's the role of gateways and there are many bits of plumbing specifically designed for that (lifecycle, configuration, etc.).  I believe you will find that Camel components are extremely easy to develop and integrate within SwitchYard, particularly when the 1.0 docs are complete. :-)

[synclpz]

Thanx much.

Is 1.0.0-SNAPSHOT stable enough to experiment with at the moment? I do ask only because it's much difficult to try to learn some new piece of SW with it's own complicated bugs :-)

Is it master branch on github to checkout 1.0 sources?

@PreDestroy is invoked as part of the lifecycle of a managed bean by CDI, so if @PreDestroy is not being called it may ben an issue with

Didn't get it, sorry. You meant "an issue with" what?

I would not implement a gateway to external systems using an implementation in SwitchYard, that's the role of gateways and there are many bits of plumbing specifically designed for that (lifecycle, configuration, etc.).  I believe you will find that Camel components are extremely easy to develop and integrate within SwitchYard, particularly when the 1.0 docs are complete. :-)

Ok, can you point me to some general steps to implement and (especially) enable for switchyard to use some custom gateway (component?), like, maybe yours 'http' or camels 'mail'. May be there are some draft docs somewhere?

I'll try to check some current component's implementations out...

[kcbabo]

My comment got clipped on the @PreDestroy answer - sorry about that.  If @PreDestroy is not being invoked then it's likely an issue with DeltaSpike integration, since SwitchYard does not invoke those methods directly.  We merely integrate with DeltaSpike via a CDI Extension.  Please file a JIRA with an example app demonstrating the problem so that we can dig deeper.

[kcbabo]

1.0 will be out very soon and the component extension mechanism will be documented at that point. I don't think it will be much help, but this was the JIRA for allowing Camel component extensions:

https://issues.jboss.org/browse/SWITCHYARD-1481

[synclpz]

Thanks for the answers. As I see in SWITCHYARD-1481, there is no plan to implement configuration via switchyard.xml configs, only by URI parameters. At least that was helpful. I'm trying to implement camel-producer at the moment. For SY0.8, I see, I should add some code to switchyard-components (like switchyard-camel-mail) to enable the use of my gateway, and then add jboss-deployment-structure dependencies on my camel-gateway, right? Would it be enough for SY to onboard my gateway?