[ 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
