The JavaScript Deployer uses Rhino to read in a JavaScript File. We also provide a set of host objects in the Mashup Server. Each host object would be a separate carbon-component while the deployer would be a component on its own. We have also created a bundle out of Rhino as well.
Problem : Before the JavaScript Deployer can read in a js, it needs to instantiate Rhino with the details of the host objects provided (We do not know how many host objects there will be in the system beforehand). Hence before the deployer deploys any scripts all the host object bundles should be active. Proposed Solution : The solution I propose is to have the host objects as fragments of the Rhino bundle. The host objects will have a component.xml in each of them that will be used to describe its details. In the activator of the Rhino bundle it will get the details of all host objects and expose it as a OSGI service. As the deployer imports packages from the Rhino bundle the Rhino bundle would start before the deployer, this also means that all host objects are available when the deployer starts doing its work. The deployer will use the exposed OSGI service to obtain details of the hostObjects and initialize them before deploying the scripts. Questions: Is this an acceptable solution. I'm sure we will come across such scenarios when getting rid of the bundle start level header. This could be a common patter for us. Using fragments has disadvantages, the main been that they cannot be versioned. But the advantage is that it resolves the dependency problem nicely. WDYT? Thanks, Keith. _______________________________________________ Mashup-dev mailing list [email protected] https://wso2.org/cgi-bin/mailman/listinfo/mashup-dev
