Return-Path: 
 <dev-return-9340-apmail-river-dev-archive=river.apache.org@river.apache.org>
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 3BF25E94B
	for <apmail-river-dev-archive@www.apache.org>;
 Sun, 17 Mar 2013 10:24:24 +0000 (UTC)
Received: (qmail 13143 invoked by uid 500); 17 Mar 2013 10:24:24 -0000
Delivered-To: apmail-river-dev-archive@river.apache.org
Received: (qmail 12997 invoked by uid 500); 17 Mar 2013 10:24:22 -0000
Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@river.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@river.apache.org>
List-Post: <mailto:dev@river.apache.org>
List-Id: <dev.river.apache.org>
Reply-To: dev@river.apache.org
Delivered-To: mailing list dev@river.apache.org
Received: (qmail 12965 invoked by uid 99); 17 Mar 2013 10:24:21 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 17 Mar 2013 10:24:21 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=5.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.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; Sun, 17 Mar 2013 10:24:16 +0000
Received: (qmail 99377 invoked by uid 16710); 17 Mar 2013 10:23:55 -0000
Received: from unknown (HELO [10.1.1.2]) ([61.9.223.241])
          (envelope-sender <jini@zeus.net.au>)
          by 207.57.65.70 (qmail-ldap-1.03) with SMTP
          for <dev@river.apache.org>; 17 Mar 2013 10:23:54 -0000
Message-ID: <51459715.8080603@zeus.net.au>
Date: Sun, 17 Mar 2013 20:12:37 +1000
From: Peter Firmstone <jini@zeus.net.au>
User-Agent: Thunderbird 2.0.0.14 (X11/20080531)
MIME-Version: 1.0
To: dev@river.apache.org
Subject: Re: OutriggerImpl starts thread in constructor
References: <5143D670.8050809@zeus.net.au> <5143E673.40901@wonderly.org>
 <514439C4.10709@zeus.net.au> <D27638E7-608F-4715-8400-B43969DA3F83@cox.net>
 <4CDFF5D7-83E1-4912-8089-2EC797476CD5@gmail.com>
In-Reply-To: <4CDFF5D7-83E1-4912-8089-2EC797476CD5@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

Provided it's used via com.sun.jini.start.ActivateWrapper it'll be ok.

NonActivatableServiceDescriptor also had to be modified to call the Starter.

Cheers,

Peter.

Dennis Reedy wrote:
> Gregg,
>
> You may be right. I'm curious, does anyone actually ever uses activation?
>
> Dennis
>
>
> On Mar 16, 2013, at 541PM, Gregg Wonderly wrote:
>
>   
>> I don't think this will work with activation because the proxy is not what is returned in that case.  It may be necessary to look at doing something in Phoenix as well, if we keep activation around.
>>
>> Gregg
>>
>> On Mar 16, 2013, at 4:22 AM, Peter Firmstone <jini@zeus.net.au> wrote:
>>
>>     
>>> I dunno, it just seems to fit so well here, I didn't even have to change the documentation.
>>>
>>> /** Generic service creation method that attempts to start the
>>>  *  services defined by the provided <code>ServiceDescriptor[]</code>
>>>  *  argument.
>>>  * @param descs The <code>ServiceDescriptor[]</code> that contains
>>>  *              the descriptors for the services to start.
>>>  * @param config The associated <code>Configuration</code> object
>>>  *               used to customize the service creation process.
>>>  * @return Returns a <code>Result[]</code> that is the same length as
>>>  *         <code>descs</code>, which contains the details for each
>>>  *         service creation attempt.
>>>  * @throws Exception If there was a problem creating the service.
>>>  * @see Result
>>>  * @see ServiceDescriptor
>>>  * @see net.jini.config.Configuration
>>>  */
>>>  private static Result[] create(final ServiceDescriptor[] descs,
>>>      final Configuration config)
>>>      throws Exception
>>>  {
>>>      logger.entering(ServiceStarter.class.getName(), "create",
>>>      new Object[] {descs, config});
>>>  ArrayList proxies = new ArrayList();
>>>
>>>  Object result = null;
>>>  Exception problem = null;
>>>      ServiceDescriptor desc = null;
>>>  for (int i=0; i < descs.length; i++) {
>>>      desc = descs[i];
>>>      result = null;
>>>      problem = null;
>>>      try {
>>>             if (desc != null) {
>>>          result = desc.create(config);
>>>                  if (result instanceof Starter) ((Starter) result).start();
>>>          }
>>>      } catch (Exception e) {
>>>          problem = e;
>>>      } finally {
>>>          proxies.add(new Result(desc, result, problem));
>>>      }
>>>  }
>>>            logger.exiting(ServiceStarter.class.getName(), "create", proxies);
>>>      return (Result[])proxies.toArray(new Result[proxies.size()]);
>>>  }
>>>
>>> Gregg Wonderly wrote:
>>>       
>>>> Looking around briefly, it seems that there is a not so great set of returned values from ServiceDescriptor.create() with activation returning the RMI GID. So a little more work to wrap everything into something implementing an interface with lifecycle management in it would be required.
>>>>
>>>> Gregg
>>>>
>>>>
>>>> On 3/15/2013 9:18 PM, Peter Firmstone wrote:
>>>>         
>>>>> I'd like to add a start() method to OutriggerImpl, so I can delay any threads from being started until after construction is complete.
>>>>>
>>>>> This is required for safe publication to comply with the JMM.
>>>>>
>>>>> Before doing so, I'd like to know how people are using Outrigger, so I can minimise unintended consequences / breakages.
>>>>>
>>>>> Comments, opinions and thoughts?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Peter.
>>>>>
>>>>>           
>>>>         
>
>
>