Christophe Herreman

By using Prana to create an application context for your Remoting enabled application, you want to achieve two things for maximum flexibility:

1. don't compile against services-config.xml
2. don't specify destinations on the client

It was with the second goal that I ran into a little issue lately when I was creating an application context for a project that uses BlazeDS. Untill now, I had mostly been using WebORB .Net for Remoting with Flex/AIR and the nice thing is that it offers you a GenericDestination. (AMFPHP offers that too btw) That way, for simple destinations, you don't actually have to specify any destinations in remoting-config.xml. When configuring remote objects on the client, you can set the "destination" property to "GenericDestination" and specify the "source" property. The "source" property then refers to the fully qualified classname of the service you want to invoke.

Here's an example:

It might be interesting to note that there must be a "GenericDestination" defined on the server. So in remoting-config.xml, you would see a destination defined as:

Opposed to a concrete defined destination like:

The wildcard (*) character is replaced at runtime with the value you specify in the "source" property of the remote object.

Switching to BlazeDS however, there is no GenericDestination available. Hm, ok then let's add one. So, I copy the GenericDestination from my WebORB remoting-config.xml to my BlazeDS remoting-config.xml, change my remote objects to specify the GenericDestination and add the source attribute:

BlazeDS will be smart enough to support this...I hope...nope! A ClassNotFoundException is thrown. Apparently BlazeDS is looking for a class named "*" and is unable to handle this.

I might have a look at the BlazeDS sources and try to figure out how this functionality could be added. Or has anyone allready done this, or knows a workaround?

---

Add to Bloglines - Digg This! - del.icio.us - Stumble It! - Twit This! - Technorati links - Share on Facebook - Feedburner