Announcement Announcement Module
No announcement yet.
Package Private Abstract Classes Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Package Private Abstract Classes

    Why does Spring Integration have so many package private abstract classes?

    I'm trying to create my own namespace and add custom transformers and filters. I keep running trouble because half the abstract classes are package private.

    For example, I'd like to implement my own version of MessageFilter. I can't extend MessageFilter because the MessageSelector instance 'selector' is private and I'd need it. My next course of action is to implement my own filter that uses AbstractMessageProcessingSelector, but I can't because it is package private.

    From a configuration standpoint for the filters in my custom namespace, I could really use AbstractDelegatingConsumerEndpointParser, but again, package private.

    Is there really a good reason to have these be package private?

    This is frustrating the heck out of me today.

  • #2
    To implement custom filter or anything for that matter you rarely need to extend anything. SI from the beginning was buit on embracing POJO model where all you need to do is inject a POJO that is compliant with the contract of the specific EIP pattern.
    For example; You were asking about custom filter:
    Here is what you would do.
    1. Create a class with a Method that takes either Message or Object and Map as an argument (if you need access to the whole message)
    public class MyFilter {
          public boolean filter(String payload, Map<String, Object> headers){
              // do whatever you want to do here as long as you return boolean
    <int:filter input-channel="inChannel" output-channel="outChannel">
        <bean class=""/>
    That's all you need
    And the same goes for all other endpoints.


    • #3
      As to your other question about reusing some of the classes for custom namespaces; just like with any other framework some of the components have been designated for internal use only especially volatile components (e.g., parsers) that change frequently as we add new functionality. If those components were public, then we would have to ensure that changes to it would bot break existing code (your code in this case) which usually puts a lot of constraint on us and slows down the progress.
      We have been relaxing some rules on some classes that have become more stable then others, but i hope you understand the main idea, so please feel free to raise a JIRA as feature request and we'll look at this.