I think this is similar to a question I had awhile back about having multiple teams working on a single Muse app. Each team would have their own muse.xml, but in the end, was there a way that Muse can automatically startup the app from multiple muse.xml files?
Looks like this is similar to Balan's request to allow muse.xml to be fragmented. The answer at the time was that this wasn't currently supported. Thinking about it now, it might also be difficult, especially if you want each muse.xml fragment to be located in a separate jar. This requires playing with the classloaders and making sure Muse is smart enough to locate all the muse.xml fragments at startup, load them in the correct order, and error handling to avoid resource clashes. In addition, to make it more complicated as Balan is proposing, the jars could be dropped in the app at anytime after startup. So not only does Muse need to locate the fragments at startup, it must also pick them up at runtime. The problem I see with this part is: if the Muse app is packaged in a War/EAR, how do you drop in jars at runtime after the app already started? Upon restart of the server, wouldn't you lose those jars because they aren't actually in the original War/EAR? Balan's proposal is good because it makes use of the "discovery" mechanism. Currently, the only way a new resource can be added at runtime is to explicitly invoke Muse to add the resource (i.e. via ResourceManager). So the proposal would allow Muse to automatically pickup the new resources at runtime, but I can see this won't be that easy to achieve. -----Original Message----- From: Balan Subramanian (JIRA) [mailto:[EMAIL PROTECTED] Sent: Monday, August 27, 2007 7:50 AM To: [email protected] Subject: [jira] Reopened: (MUSE-243) Dynamic discovery and aggregation of resource types [ https://issues.apache.org/jira/browse/MUSE-243?page=com.atlassian.jira.p lugin.system.issuetabpanels:all-tabpanel ] Balan Subramanian reopened MUSE-243: ------------------------------------ The OSGi fix provided by Joel only satisfies: "As an additional enhancement, it is desired that in addition to support archive files, Muse supports this feature for OSGi bundles by registering with the OSGi container's bundle registry. This enhancement is applicable only when the runtime environment for Muse is OSGi." We still need to provide the base feature which allows muse.xml fragments to be provided separately in separate JAR files. > Dynamic discovery and aggregation of resource types > --------------------------------------------------- > > Key: MUSE-243 > URL: https://issues.apache.org/jira/browse/MUSE-243 > Project: Muse > Issue Type: New Feature > Components: Core Engine - Resource and Capability APIs > Reporter: Balan Subramanian > Assignee: Dan Jemiolo > Fix For: 2.3.0 > > > In some cases all resource type definitions are not available at the time the Muse runtime starts. So even though multiple resource types can be hosted by a single Muse instance, all the resource type definitions must be available before Muse starts and listed in muse.xml. It is desired that Muse be made dynamic so that it can monitor a particular folder where an archive (JAR for example) is dropped. This archive will contain the necessary classes, descriptors, router entries etc. and a muse.xml fragment which will be used by Muse to instantiate the specified instances of that resource type. As an additional enhancement, it is desired that in addition to support archive files, Muse supports this feature for OSGi bundles by registering with the OSGi container's bundle registry. This enhancement is applicable only when the runtime environment for Muse is OSGi. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
