JavaAdapter's initialize() method not called when using

[dirk.eismann]

I just found that when using the MessageBrokerFactoryBean, the default JavaAdapter's (or a subclass of it, see remoting-config.xml) initialize() method is never invoked.

In contrast, when using plain-vanilla-default destinations in the remoting-config.xml the initialize() method on the Adapter is called.

Normally, invocation of the initialize() method happens when the configureBroker() Method is called on the MessagingConfiguration. This method will call createDestination() for every hard-wired Destination found in the remoting-config.xml. Finally, the createDestination() calls createAdapter() which in turn creates the Adapter instance and calls initialize() on it.

We use custom JavaAdapters which use the initialize() method to set things up internally but this currently does not work with Spring BlazeDS Integration.

I'll create an issue for this in JIRA.

Dirk.

[dirk.eismann]

here's the Jira link:
http://jira.springframework.org/browse/FLEX-26

I'd love to see this getting fixed for M2

Thanks,
Dirk.

[dirk.eismann]

btw, it seems as if this could be fixed quite easily by initializing the adapter from within the afterPropertiesSet() method of the FlexRemotingServiceExporter just after the RemotingDestination got created.

Dirk.

[jeremyg484]

Hmmm...I'm not sure that calling initialize() from our code is really the right approach. It seems to me that the initialize method is really intended for passing XML configuration properties to the object, but from the FlexRemotingExporter we have no such data to pass.

What are you actually doing in the initialize() method of your custom adapters?

What if you could configure the adapters as Spring beans? I've already considered that we would need to provide that capability if we want to enable getting rid of remoting-config.xml altogether. Would that not be a better option?

[dirk.eismann]

I agree: in a final release version of Spring BlazeDS Integration it would be ideal if Channels, Services, Adapters and Destinations could be created without any BlazeDS specific XML config but directly using Spring.

Still, the initialize() method is part of the public BlazeDS API for Adapters so I think this should API should be respected by Spring and invoked transparently. We've used this way of configuring together with our JavaAdapter subclasses to add additional configuration to the adapter. Another use case is the Gilead project (http://noon.gilead.free.fr/gilead/) which also uses a custom JavaAdapter (PersistentAdapter, see here at the bottom of the pade http://noon.gilead.free.fr/gilead/in...e=flex-blazeds) that needs to get configured "statically" - and this one is currently not working with Spring BlazeDS out of the box for the above reason.

Actually, in the BlazeDS XML configuration there are quite a few ways to assign an Adapter to a Destination, starting by setting up a default adapter (like it is in the default installation) down to referencing the Adapter in the Destination.

The only way in plain BlazeDS config files to configure an Adapter is by using the ConfigMap (i.e. setting up an XML structure in the <properties/> node of the Adapter) - this works very well and IMHO this still should be supported later in Spring BlazeDS Integration.

E.g. I could think of something like this:

<bean id="myAdapter" class="some.custom.JavaAdapterSubclass">
<property name="configMap" class="something.that.wraps.ConfigMap">
<map>
<entry>
<key>whatEver</key>
<value>something</value>
</entry>
</map>
</propery>
</bean>

this would still be compatible to the Adapter API, so the Adapter could still be used in a default BlazeDS environment that does not use Spring at all.

You know what I mean?

Dirk.