[
https://issues.apache.org/jira/browse/ARTEMIS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16000900#comment-16000900
]
ASF GitHub Bot commented on ARTEMIS-898:
----------------------------------------
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/1258
Like how we load the ProtocolManagers...
Each jar defines a
org.apache.activemq.artemis.spi.core.protocol.ProtocolManagerFactory file
Then on RemotingServiceImpl::
```
private void resolveProtocols(ClassLoader loader) {
ServiceLoader<ProtocolManagerFactory> serviceLoader =
ServiceLoader.load(ProtocolManagerFactory.class, loader);
loadProtocolManagerFactories(serviceLoader);
}
/**
* Loads the protocols found into a map.
*
* @param protocolManagerFactoryCollection
*/
private void
loadProtocolManagerFactories(Iterable<ProtocolManagerFactory>
protocolManagerFactoryCollection) {
for (ProtocolManagerFactory next : protocolManagerFactoryCollection) {
MessagePersister.registerProtocol(next);
String[] protocols = next.getProtocols();
for (String protocol : protocols) {
ActiveMQServerLogger.LOGGER.addingProtocolSupport(protocol,
next.getModuleName());
protocolMap.put(protocol, next);
}
}
}
```
Perhaps we could instruct users to do something similar. Just having this
definition done.
We would have to provide a XML property to resolve plugins, being defaulted
to false if we did this.
> Artemis Plugin Support
> ----------------------
>
> Key: ARTEMIS-898
> URL: https://issues.apache.org/jira/browse/ARTEMIS-898
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
> Affects Versions: 2.next
> Reporter: Matt Pavlovich
> Assignee: Christopher L. Shannon
> Fix For: 2.next
>
>
> ActiveMQ 5.x currently has a number of extension points via Plugins, or
> simple Spring bean wiring. Artemis should provide extension points to meet
> various requirements.
> The protocol interceptors are handy, but also limiting in that each plugin
> would need to be implemented for every protocol. Feels like there should be
> defined extension point(s) within the broker.
> Core Broker Plugins:
> 1. Message header / property manipulation
> 2. Message body manipulation
> 3. Activity tracing (broker becomes master, network bridge start/stop,
> message rcv/sent/ack/rollback, consumer/producer add/remove, broker
> add/remove, destination add/remove, connection add/remove, fast producer/slow
> consumer, etc)
> a. Audit / trace logs
> b. Triggers based on events
> ref:
> http://activemq.apache.org/maven/apidocs/org/apache/activemq/broker/MutableBrokerFilter.html
> Additional extension point:
> DestinationPolicies: Ability to impact destination behaviors for dispatch,
> subscription policies, etc.
> Side benefit regarding Advisory Support:
> If the plugin framework can get squared away, an upside could be that
> Advisory support becomes a plugin vs an ingrained feature and we could have
> more control over configuration and behavior.
> From ARTEMIS-17
> Support for using Camel as an interceptor/plugin
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
