Return-Path: 
 <camel-dev-return-7911-apmail-activemq-camel-dev-archive=activemq.apache.org@activemq.apache.org>
Delivered-To: apmail-activemq-camel-dev-archive@locus.apache.org
Received: (qmail 5448 invoked from network); 10 Dec 2008 13:02:47 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 10 Dec 2008 13:02:47 -0000
Received: (qmail 77328 invoked by uid 500); 10 Dec 2008 13:03:00 -0000
Delivered-To: apmail-activemq-camel-dev-archive@activemq.apache.org
Received: (qmail 77306 invoked by uid 500); 10 Dec 2008 13:03:00 -0000
Mailing-List: contact camel-dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:camel-dev-help@activemq.apache.org>
List-Unsubscribe: <mailto:camel-dev-unsubscribe@activemq.apache.org>
List-Post: <mailto:camel-dev@activemq.apache.org>
List-Id: <camel-dev.activemq.apache.org>
Reply-To: camel-dev@activemq.apache.org
Delivered-To: mailing list camel-dev@activemq.apache.org
Received: (qmail 77295 invoked by uid 99); 10 Dec 2008 13:03:00 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Dec 2008 05:03:00 -0800
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of james.strachan@gmail.com
 designates 74.125.44.157 as permitted sender)
Received: from [74.125.44.157] (HELO yx-out-1718.google.com) (74.125.44.157)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Dec 2008 13:01:26 +0000
Received: by yx-out-1718.google.com with SMTP id 3so183777yxi.86
        for <camel-dev@activemq.apache.org>;
 Wed, 10 Dec 2008 05:02:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:to
         :subject:in-reply-to:mime-version:content-type
         :content-transfer-encoding:content-disposition:references;
        bh=5DPnMastWvf2sKhAwiJI9Xq1Nb/2TkJxv0vL/1VFR/E=;
        b=oIM85Afo1Oyds9WtBg/14xX1vJsoyiyOzWd855tFUMhYhQVJ1hlNsctZZWyZ3hjbOO
         UbniXOFxixuzf28yfvBVSG7r+okTJGD39aOgFFe7CiHA4lkgwVWIdNlsnOnTqsnd2oBC
         AhVeVNSV9v3sXkLqsFkGTppoFghyutf2pD+Yc=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=RHAtTIMO3hZ5iaEtcY7nrx+EYyOQNB1FdP1Yf0dR+9aecF6U+c1T2Pq0RmkAekcE2u
         FLxwjkN7gbXWVnXZbpGm+CzqSc1gyQnlI7Jghx9ClfpMFTK4pnRUBr3xrig3mW3b6v4O
         E46KlovtQmRdJfA381UnpyuucbdHoqsiVISps=
Received: by 10.150.191.10 with SMTP id o10mr2070942ybf.205.1228914134417;
        Wed, 10 Dec 2008 05:02:14 -0800 (PST)
Received: by 10.151.119.3 with HTTP; Wed, 10 Dec 2008 05:02:14 -0800 (PST)
Message-ID: <ec6e67fd0812100502r4514903ev41cdec0fba853a4e@mail.gmail.com>
Date: Wed, 10 Dec 2008 13:02:14 +0000
From: "James Strachan" <james.strachan@gmail.com>
To: camel-dev@activemq.apache.org
Subject: Re: Do we really need the generate parameter in the ProcessorType?
In-Reply-To: <493F35C4.90806@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <493F35C4.90806@gmail.com>
X-Virus-Checked: Checked by ClamAV on apache.org

2008/12/10 Willem Jiang <willem.jiang@gmail.com>:
> Hi,
>
> When I start to work on CAMEL-1171, I found that we don't need to use
> the <Type extends ProcessorType> in the ProcessorType class definition.
>
> public abstract class ProcessorType<Type extends ProcessorType> extends
> OptionalIdentifiedType<Type> implements Block
>
> For the common usecase to() method, it just need to return a
> ProcessorType, I don't think we will call the
> setParallelProcessing(true) after that, if we create a MulticastType first.
>
> Just like this
>
> from("direct:start").multicast().setParallelProcessing(true)...
> to("direct:endpointA").to("direct:endpointB");
>
> we won't write the rule like this
> from("direct:start").multicast()...
> to("direct:endpointA").setParallelProcessing(true).to("direct:endpointB");
>
> Now , I just have a question about the OptionalIdentifiedType, since I
> never use it. I don't know when we will call the
> OptionalIdentifiedType's description method.
> Can we just change the ProcessorType definition like this ?
>
> public abstract class ProcessorType extends
> OptionalIdentifiedType<ProcessorType> implements Block
>
> Is they something that I'm missing?

The generics use is kinda complex in the DSL - if you try remove stuff
like this you'll probably be surprised by what breaks :).

One of the main reasons for it being there is AFAIK to allow derived
classes to return the derived type in blocks. e.g. try remove it and
see if the choice()/when()/otherwise() stuff still compiles. See how
the parameterized Type is returned by to() or filter() etc.

The generics compiler in Java is a bit pants in that it only tries so
far to resolve generic types and just defaults to Object after a
while; so we've gotta be careful using them - but they can be useful
in the DSL.

-- 
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/