Return-Path: X-Original-To: apmail-river-dev-archive@www.apache.org Delivered-To: apmail-river-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D778F10233 for ; Fri, 7 Mar 2014 18:09:21 +0000 (UTC) Received: (qmail 96329 invoked by uid 500); 7 Mar 2014 18:09:21 -0000 Delivered-To: apmail-river-dev-archive@river.apache.org Received: (qmail 96312 invoked by uid 500); 7 Mar 2014 18:09:21 -0000 Mailing-List: contact dev-help@river.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@river.apache.org Delivered-To: mailing list dev@river.apache.org Received: (qmail 96304 invoked by uid 99); 7 Mar 2014 18:09:21 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Mar 2014 18:09:21 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [207.57.65.70] (HELO zeus.net.au) (207.57.65.70) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Mar 2014 18:09:14 +0000 Received: (qmail 56052 invoked by uid 16710); 7 Mar 2014 18:08:53 -0000 Received: from unknown (HELO [10.124.140.103]) ([49.180.114.49]) (envelope-sender ) by 207.57.65.70 (qmail-ldap-1.03) with SMTP for ; 7 Mar 2014 18:08:53 -0000 From: Peter Reply-To: Peter To: dev@river.apache.org Subject: Re: River-436 - need some explanation of preferred class provider X-Mailer: Modest 3.2 References: <5313816B.9030703@xpro.biz> <1394183922.8503.24.camel@Nokia-N900> <8B5726EF-2BB5-435B-A778-F81A0FC3AE52@cox.net> In-Reply-To: <8B5726EF-2BB5-435B-A778-F81A0FC3AE52@cox.net> Content-Type: multipart/alternative; boundary="=-sXVXQs7+Y01ts3GHuKD7" Date: Sat, 08 Mar 2014 04:08:44 +1000 Message-Id: <1394215724.9471.5.camel@Nokia-N900> Mime-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org --=-sXVXQs7+Y01ts3GHuKD7 Content-Type: text/plain; charset=utf-8 Content-ID: <1394215723.9471.2.camel@Nokia-N900> Content-Transfer-Encoding: 8bit GlassFish and Jboss do dynamic stub generation for IIOP proxy's too, now that would be cool. Cheers, Peter. ----- Original message ----- > Greg is referring to the fact that Jeri provides the ability to ship a > java.reflection.Proxy object to the report host as the service > implementation, instead of having to ship the actual class as a > serializable endpoint.  This is a big difference.  Adding endpoint > implementations into this is like apples and oranges.  Yes, if there is > “code” needed, it needs to be downloaded.  But, dynamic proxies take > away the need for code to be downloaded, unless you need a smart proxy. > > Gregg Wonderly > > On Mar 7, 2014, at 10:32 AM, Michał Kłeczek > wrote: > > > Sure there is a need for code downloading for JERI proxies. You seem > > to assume  no custom endpoint implementations. > > > > There is really no difference between dynamic proxy and "normal" > > object. > > > > Regards, > > > > On Friday, March 07, 2014 09:32:04 AM Greg Trasuk wrote: > > > > > > Now, dynamic proxies are a different story, and JERI already uses the > > > dynamic proxy mechanism.  There’s no need, for example to download an > > > implementation class for an object that is directly exported - you > > > only really need the service interface to be available locally. > > > > > > > > > Cheers, > > > > > > Greg Trasuk > > > > -- > > Michał Kłeczek > > XPro Sp. z o. o. > > ul. Borowskiego 2 > > 03-475 Warszawa > > Polska > --=-sXVXQs7+Y01ts3GHuKD7--