Issue Details (XML | Word | Printable)

Key: GDS-54
Type: New Feature New Feature
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Franck Wolff
Reporter: Cristian Pascu
Votes: 1
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
GraniteDS

Provide a way to dinamically add destinations to applications using Granite Data Services

Created: 13/Nov/07 10:53 AM   Updated: 23/Apr/08 06:43 PM   Resolved: 23/Apr/08 06:43 PM
Component/s: Spring services
Affects Version/s: 0.4.0
Fix Version/s: 1.1.0_RC1

File Attachments: 1. Java Source File FlexService.java (0.5 kB) 30/Jan/08 11:27 AM - Nico Krijnen
2. XML File services-config.xml (1 kB) 30/Jan/08 11:26 AM - Nico Krijnen
3. Text File Services.mxml.txt (1 kB) 30/Jan/08 11:27 AM - Nico Krijnen
4. Java Source File SpringServiceFactory.java (3 kB) 30/Jan/08 11:26 AM - Nico Krijnen
5. Java Source File SpringServiceInvoker.java (0.5 kB) 30/Jan/08 11:26 AM - Nico Krijnen



 Description  « Hide
In an web application that needs to have some kind of modularity, having one single configuration file for Flex Services will enforce each module to register it's destination in this configuration file. Although I don't know if it's possible in Flex DS, I guess that it will be nice to have this kind of feature in GDS.

I imagine three different solutions, not all of them being so nice:
1. Provide an annotation for classes that want to be exposed as destinations. Using a Spring BeanFactoryPostProcessor, on can easily discover all beans inside application context that have this annotation and automatically register those beans as GDS destinations.

2. Create a FactoryBean for Destination's to be used inside an application context that will instantiate destinations and register them inside ServicesConfig under the specified Service.

3. Use custom namespaces inside spring configuration files. Need to create an XSD for destination elements and other configuration options specific to GDS. I have noticed that is very easy to transform a org.w3c Dom document into a JDOM document so no need to change granite config classes.

I have started to implement something and would be more then happy to contribute patches but I like to hear first from you what do you think.

Sort Order: Ascending order - Click to sort in descending order
Franck Wolff added a comment - 17/Dec/07 05:48 PM
We'll see what is done in Flex3 and BlazeDS.

Cristian Pascu added a comment - 30/Jan/08 09:45 AM
Do you think that for 1.0.0 version, you can at least provide add* methods for services, channels and factories in ServicesConfig class? One should be able to use this methods to add more destinations at runtime.

Nico Krijnen added a comment - 30/Jan/08 11:26 AM
I badly needed this so implemented it myself. It is not the most elegant solution, but it was a minimal modification and it works fantastic.

I created a custom SpringServiceFactory to retrieve a bean from spring using the name specified in the 'source' property of the flex RemoteObject.
Additionaly the SpringServiceFactory validates the resulting bean, making sure it is marked with a custom FlexService annotation so only those beans are accessible through the gateway.

Franck Wolff added a comment - 30/Jan/08 04:52 PM
I have added 3 new methods in the trunk:

    public void addService(Service service) {
        services.put(service.getId(), service);
    }

    public void addChannel(Channel channel) {
        channels.put(channel.getId(), channel);
    }

    public void addFactory(Factory factory) {
        factories.put(factory.getId(), factory);
    }

It will be in the 1.0.0 release, thanks for this suggestion.

Cristian Pascu added a comment - 31/Jan/08 09:42 AM
Great! Is just great!

Yesterday I have created a mechanism for dynamically detecting service destination from Spring configured beans by using an annotation @Destination, and a BeanPostProcessor and a builder that generates and XML document on the fly to create a ServicesConfig instance. This addition will help me to avoid the generation of XML document. However, for 0.4.0 version we are using, this generation is still needed.

We look forward to the new 1.0.0 version which, as I can see, is about to be released! Thanks a lot for the good work!

Cristian Pascu added a comment - 19/Feb/08 04:02 PM
Hi Franck!

Starting to work with GraniteDS 1.0.0, I have noticed that the behavior for loading ServicesConfig has changed, meaning, that GDS does not set an servlet context attribute with the loaded configuration for later reuse but, as far as I can tell, rather reload it at each filter initialization. Perhaps this filter is initialized only once. But since the services config is visible only inside the filter, as it is private, makes it impossible to make future changes to this configuration programatically. I had to copy/paste the AMFMessageFilter in order to insert dynamic destination discovery with Spring.

Am I missing something from this change?

Franck Wolff added a comment - 23/Apr/08 06:43 PM
Done.