Announcement Announcement Module
Collapse
No announcement yet.
Doubt about a particular situation about Spring Integration API Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Doubt about a particular situation about Spring Integration API

    Dear Members

    In Spring Integration 2.0.4.RELEASE API, I did realize the follow

    For the Class NullChannel in its API appear

    Code:
    public class NullChannel
    extends java.lang.Object
    implements PollableChannel
    If I see the source code for this class I see

    Code:
    package org.springframework.integration.channel;
    
    import org.apache.commons.logging.Log;
    import org.apache.commons.logging.LogFactory;
    
    import org.springframework.integration.Message;
    import org.springframework.integration.core.PollableChannel;
    
    /**
     * A channel implementation that essentially behaves like "/dev/null".
     * All receive() calls will return <em>null</em>, and all send() calls
     * will return <em>true</em> although no action is performed.
     * Note however that the invocations are logged at debug-level.
     * 
     * @author Mark Fisher
     */
    public class NullChannel implements PollableChannel {
    
    	private final Log logger = LogFactory.getLog(this.getClass());
    OK, I know that practically each Java class by default extends the java.lang.Object, and we can override for example the method toString()

    But why appear explicitly the red part?

    Code:
    public class NullChannel
    extends java.lang.Object
    implements PollableChannel
    If I see the API of many "similar" classes about NullChannel never appear the red part, I mean, for example, for

    QueueChannel API
    appear

    Code:
    public class QueueChannel
    extends AbstractPollableChannel
    and its source code is

    Code:
    package org.springframework.integration.channel;
    
    import java.util.ArrayList;
    import java.util.List;
    import java.util.concurrent.BlockingQueue;
    import java.util.concurrent.LinkedBlockingQueue;
    import java.util.concurrent.TimeUnit;
    
    import org.springframework.integration.Message;
    import org.springframework.integration.core.MessageSelector;
    import org.springframework.util.Assert;
    
    /**
     * Simple implementation of a message channel. Each {@link Message} is placed in
     * a {@link BlockingQueue} whose capacity may be specified upon construction.
     * The capacity must be a positive integer value. For a zero-capacity version
     * based upon a {@link java.util.concurrent.SynchronousQueue}, consider the
     * {@link RendezvousChannel}.
     * 
     * @author Mark Fisher
     * @author Oleg Zhurakousky
     */
    public class QueueChannel extends AbstractPollableChannel {
    
    	private final BlockingQueue<Message<?>> queue;
    For RendezvousChannel API
    appear
    Code:
    public class RendezvousChannel
    extends QueueChannel
    and its source code is

    Code:
    package org.springframework.integration.channel;
    
    import java.util.concurrent.SynchronousQueue;
    
    import org.springframework.integration.Message;
    
    /**
     * A zero-capacity version of {@link QueueChannel} that delegates to a
     * {@link SynchronousQueue} internally. This accommodates "handoff" scenarios
     * (i.e. blocking while waiting for another party to send or receive).
     * 
     * @author Mark Fisher
     */
    public class RendezvousChannel extends QueueChannel {
    
    	public RendezvousChannel() {
    		super(new SynchronousQueue<Message<?>>());
    	}
    
    }
    Finally for PriorityChannel API appear

    public class PriorityChannel
    extends QueueChannel
    and its source code is

    Code:
    package org.springframework.integration.channel;
    
    import java.util.Comparator;
    import java.util.concurrent.PriorityBlockingQueue;
    
    import org.springframework.integration.Message;
    import org.springframework.integration.MessageHeaders;
    import org.springframework.integration.util.UpperBound;
    
    /**
     * A message channel that prioritizes messages based on a {@link Comparator}.
     * The default comparator is based upon the message header's 'priority'.
     * 
     * @author Mark Fisher
     */
    public class PriorityChannel extends QueueChannel {
    Why this behaviour?

    Of course for all and each class in its API appear

    Methods inherited from class java.lang.Object
    clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait
    Thanks in advanced

  • #2
    That's how Javadoc always works (see for example java.io.File): on the top of the page you'll see the complete class hierarchy, which always has java.lang.Object at the root. In the section below (where your observation comes from) only the direct parent in that hierarchy is show, which is java.lang.Object if the class doesn't explicitly extend any other class in the source code.

    Comment


    • #3
      Hello Alexander

      That's how Javadoc always works (see for example java.io.File): on the top of the page you'll see the complete class hierarchy, which always has java.lang.Object at the root.
      Yes totally agree

      In the section below (where your observation comes from) only the direct parent in that hierarchy is show, which is java.lang.Object if the class doesn't explicitly extend any other class in the source code.
      Oh, I forgot totally this part , so shame, this is the consequences about work practically all the day

      Thank you

      Comment

      Working...
      X