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]
