[ http://issues.apache.org/jira/browse/MUSE-26?page=comments#action_12420213 ]
Dan Jemiolo commented on MUSE-26: --------------------------------- Completed - see commit message for details: http://svn.apache.org/viewvc?view=rev&revision=420724 > Ability of deployers to specify "default" capbility implementations that > cannot be overridden > --------------------------------------------------------------------------------------------- > > Key: MUSE-26 > URL: http://issues.apache.org/jira/browse/MUSE-26 > Project: Muse > Type: New Feature > Environment: Axis2 and OSGi > Reporter: Dan Jemiolo > > Right now, Muse allows users to specify the implementation class for every > capability that they add to a resource type. In some cases, a vendor that is > deploying Muse may wish to require use of a certain implementation that is > not easily replaced by the user. This allows the Muse application developer > to provide certain QoS guarantees. > There is a fairly elegant solution to this - proposal is below: > Users could provide a certain (optional, but standard) .properties file in > the classpath ( call it org/apache/muse/core/RequiredImplementations, or > something), and that file will be consulted whenever a capability is being > read from the deployment descriptor. The .properties file would be a set of > {capability URI, capability class} pairs, and it would take precedence over > what was found in the deployment descriptor. > so, instead of today's set up, where a user might have: > <resource> > ... > <capability> > <!-- bad - user could swap out WS-N impl even if we don't want them too > --> > <capability-uri> > http://docs.oasis-open.org/wsn/bw-2/NotificationProducer > </capability-uri> > <java-capability-class> > com.ibm.websphere.wsspi.notification.NotificationProducerImpl > </java-capability-class> > </capability> > <capability> > <capability-uri> > http://www.mycompany.com/example/my/capability > </capability-uri> > <java-capability-class> > com.mycompany.example.my.CapabilityImpl > </java-capability-class> > </capability> > </resource> > we would instead have: > <resource> > ... > <capability> > <!-- notice - no capability class - this is in .properties file --> > <capability-uri> > http://docs.oasis-open.org/wsn/bw-2/NotificationProducer > </capability-uri> > </capability> > <capability> > <capability-uri> > http://www.mycompany.com/example/my/capability > </capability-uri> > <java-capability-class> > com.mycompany.example.my.CapabilityImpl > </java-capability-class> > </capability> > </resource> > with this line in the RequiredImplementations.properties file: > http://docs.oasis-open.org/wsn/bw-2/NotificationProducer = > com.mycompany.ws.notification.NotificationProducerImpl > If/When the user decides to use a capability provided by the platform, he > will only specify the URI in the deployment descriptor, and the > implementation will be picked up from the .properties file. If the user tried > to sneak one by us and add the <java-capability-class/> element back into the > second descriptor example, it wouldn't work because the .properties file > would have precedence. Adding the element back in would result in a message > that said: > "A capability with URI {$capability-URI} already been defined with > {$details-of-capability}." > This allows users to build up resource types by only aggregating the > capabilities they want (that is, they don't have to include WSN if they don't > need it), but prevents them from adding new implementations of capabilities > considered "very important" (so when they do use WSN, it will be the > platform's desired impl). > All that would be left (from a deployer's perspective) is to move the .jar > file that contained the .properties file into non-user-space on the > classpath. this would prevent a user from replacing the .properties file > unless they went digging. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
