Results 1 to 3 of 3

Thread: Package Private Abstract Classes

  1. #1
    Join Date
    Mar 2012
    Posts
    2

    Angry 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. #2
    Join Date
    Jan 2008
    Location
    Mohnton, PA USA (that's near Philadelphia)
    Posts
    2,148

    Default

    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)
    Code:
    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
          }
    }
    
    XML:
    <int:filter input-channel="inChannel" output-channel="outChannel">
        <bean class="foo.bar.MyFilter"/>
    </int:filter>
    That's all you need
    And the same goes for all other endpoints.

  3. #3
    Join Date
    Jan 2008
    Location
    Mohnton, PA USA (that's near Philadelphia)
    Posts
    2,148

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •