Re: CXF DOSGi: Idea for replacement of IntentMap reading
Hi Christian On 16/11/12 06:59, Christian Schneider wrote: Currently we manually use spring-dm to read the IntentMap from the dsw bundle as well as from bundles implementing or using OSGi services. This has some drawbacks: - As IntentMap is defined in the dsw bundle the user bundles depend on the dsw bundle - User bundles and dsw bundle depend on spring dm - It is not possible to use other ways to define intents (e.g. blueprint or by hand) So I propose to replace this with a different aproach: First I would like to replace the IntentMap with a simple HashMap so we do not need a depdendency on dsw. To also avoid to directly use spring dm I propose we define the default intents in java code. For user defined intents we could use a service. So the user bundles would define the intent map themselves and offer it as an OSGi service. The dsw bundle then would check for these services. As the Map is not a unique identifier we could use a property to mark a service as a intent map. The solution has one drawback though. It is incompatible with the current way of defining intents. Do you think this is a problem? Do you see any other problems with proposed solution? Btw. I think the current intent map reading has a bug. We use getIntentMap for loading the default intents as well as the use intents. Inside getIntentMap we cache the loaded IntentMap. So only the first call will load something. So I am not sure if user intents work at all at the moment. Is this correct? See also: https://issues.apache.org/jira/browse/DOSGI-86 https://issues.apache.org/jira/browse/DOSGI-115 I'm not sure anyone uses custom intents, there were some ideas from users on how to get custom intents, suggesting how it can be done based on the existing approach but it was too difficult as far as I recall. So what you suggest seems more flexible and OSGI-friendly. Typically, reacting to an intent means adding a CXF-level interceptor. How will it work with your approach ? Cheers, Sergey Christian -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: CXF DOSGi: Idea for replacement of IntentMap reading
On 11/16/2012 11:33 AM, Sergey Beryozkin wrote: Hi Christian I'm not sure anyone uses custom intents, there were some ideas from users on how to get custom intents, suggesting how it can be done based on the existing approach but it was too difficult as far as I recall. So what you suggest seems more flexible and OSGI-friendly. Typically, reacting to an intent means adding a CXF-level interceptor. How will it work with your approach ? Basically it is the same with my aproach. We get the intent map using a service instead of directly reading the config file but everything after this point is the same. The only thing I can imagine is that there may be a timing issue. When we check for services of type intent map before the service is exported we have a problem. Christian
Re: CXF DOSGi: Idea for replacement of IntentMap reading
Contributing new intents using the whiteboard pattern. Sounds like an interesting idea! One thing you could think of is to create a separate bundle that provides backward compatibility. I mean it could read the intent-map.xml (using any XML parser, doesn't have to be Spring) as we have it today and register the appropriate whiteboard services. If people don't need to backward compatibility they wouldn't install this bundle... Just my 2c, David On 16 November 2012 10:50, Christian Schneider ch...@die-schneider.netwrote: On 11/16/2012 11:33 AM, Sergey Beryozkin wrote: Hi Christian I'm not sure anyone uses custom intents, there were some ideas from users on how to get custom intents, suggesting how it can be done based on the existing approach but it was too difficult as far as I recall. So what you suggest seems more flexible and OSGI-friendly. Typically, reacting to an intent means adding a CXF-level interceptor. How will it work with your approach ? Basically it is the same with my aproach. We get the intent map using a service instead of directly reading the config file but everything after this point is the same. The only thing I can imagine is that there may be a timing issue. When we check for services of type intent map before the service is exported we have a problem. Christian
Re: CXF DOSGi: Idea for replacement of IntentMap reading
I also thought about this. We could have a bundle that reads intent xmls using spring dm. With a simple parse I think it would not work as we need the cxf namespaces to create features from the xml definitions. So we would not get rid of spring dm. I think the effort to convert an existing intentmap xml is quite low. Basically you would just have to switch from IntentMap to a normal map, export the service and move the xml file to the spring dm directory so it is picked up. So if not many people have used this feature we may just start with instructions for the conversion and if people need compatibility we could provide the above bundle in the next version. Christian On 11/16/2012 02:56 PM, David Bosschaert wrote: Contributing new intents using the whiteboard pattern. Sounds like an interesting idea! One thing you could think of is to create a separate bundle that provides backward compatibility. I mean it could read the intent-map.xml (using any XML parser, doesn't have to be Spring) as we have it today and register the appropriate whiteboard services. If people don't need to backward compatibility they wouldn't install this bundle... Just my 2c, David On 16 November 2012 10:50, Christian Schneider ch...@die-schneider.netwrote: On 11/16/2012 11:33 AM, Sergey Beryozkin wrote: Hi Christian I'm not sure anyone uses custom intents, there were some ideas from users on how to get custom intents, suggesting how it can be done based on the existing approach but it was too difficult as far as I recall. So what you suggest seems more flexible and OSGI-friendly. Typically, reacting to an intent means adding a CXF-level interceptor. How will it work with your approach ? Basically it is the same with my aproach. We get the intent map using a service instead of directly reading the config file but everything after this point is the same. The only thing I can imagine is that there may be a timing issue. When we check for services of type intent map before the service is exported we have a problem. Christian