You are viewing a plain text version of this content. The canonical link for it is here.
Posted to muse-dev@ws.apache.org by "Dan Jemiolo (JIRA)" <ji...@apache.org> on 2006/07/14 19:07:15 UTC
[jira] Closed: (MUSE-26) Ability of deployers to specify "default"
capbility implementations that cannot be overridden
[ http://issues.apache.org/jira/browse/MUSE-26?page=all ]
Dan Jemiolo closed MUSE-26.
---------------------------
Fix Version/s: 2.0.0 M2
Resolution: Fixed
Assignee: Dan Jemiolo
> 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
> Issue Type: New Feature
> Environment: Axis2 and OSGi
> Reporter: Dan Jemiolo
> Assigned To: Dan Jemiolo
> Fix For: 2.0.0 M2
>
>
> 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: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org