Responding to this question in JIRA: http://track.sipfoundry.org/browse/XCF-2969#action_32865
I'd prefer to have this discussion here in case Kevin or someone else has something to add. Or just tell me that I am wrong... Bogdan: If I understand this correctly the goal is to be able to add new (generic) service without adding a new Java class representing a new service. Or - in other words - add support for new services without writing any Java code. I was trying to think of several ways work around "one class - one service" limitation. But as long as we keep all the services in one table there is no going around the fact that you have to have a difference discriminator value for each class. And since beanId is used as a discriminator value you need a new class for each service. I might be wrong but I see only 2 options: (1) require that all services do define a new java class - you could put a definition of such service in plugins directory as an example I do not think it's going to be difficult for anyone who'd be interested in adding new service to follow the example (BTW: C is probably an overkill here, script would do just fine). (2) keep generic services in a separate table and carefully hide all the difference between two types (generic and non-generic) of the services inside of SipServiceManager. You'd need to change the inheritance hierarchy to split generic from non-generic services on one level so that generic service does not get mapped automatically, but all non-generic do. I think that 1 is acceptable (and certainly easier). Kevin - what do you think? BTW: I looked at the patch and I am not sure why you need any specific code for OemServices - such as getAllOemServiceBeans, searchForNewOemServices. After all every service is the same: there should be no difference between built-in services and services defined by plug-ins. D. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
