Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 88176 invoked from network); 30 Mar 2006 19:18:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 30 Mar 2006 19:18:03 -0000 Received: (qmail 65479 invoked by uid 500); 30 Mar 2006 19:17:51 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 65445 invoked by uid 500); 30 Mar 2006 19:17:51 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 65434 invoked by uid 99); 30 Mar 2006 19:17:51 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Mar 2006 11:17:51 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [192.87.106.226] (HELO ajax.apache.org) (192.87.106.226) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Mar 2006 11:17:50 -0800 Received: from ajax (localhost.localdomain [127.0.0.1]) by ajax.apache.org (Postfix) with ESMTP id A18CF6ACB3 for ; Thu, 30 Mar 2006 20:17:29 +0100 (BST) Message-ID: <1949497531.1143746249658.JavaMail.jira@ajax> Date: Thu, 30 Mar 2006 20:17:29 +0100 (BST) From: "Davanum Srinivas (JIRA)" To: axis-dev@ws.apache.org Subject: [jira] Updated: (AXIS2-341) service deployment In-Reply-To: <2116762785.1134749146243.JavaMail.jira@ajax.apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ http://issues.apache.org/jira/browse/AXIS2-341?page=3Dall ] Davanum Srinivas updated AXIS2-341: ----------------------------------- Priority: Blocker (was: Major) Blocker for 1.0 release?=20 > service deployment > ------------------ > > Key: AXIS2-341 > URL: http://issues.apache.org/jira/browse/AXIS2-341 > Project: Apache Axis 2.0 (Axis2) > Type: Improvement > Components: deployment > Versions: 0.94 > Environment: not pertinent > Reporter: Tony Dean > Assignee: Deepal Jayasinghe > Priority: Blocker > > Original email: > I have been using the "public void init()" method of my service implemena= tion to perform one-time initialization. I can't remember how I stumbled a= cross this functionality, but it would be nice for you to define an impleme= nation interface that describes this functionality. Maybe you have and I j= ust do not know about it. When I tested my service, it appeared that the e= ngine called init() on every operation invocation. I did not spend much ti= me looking through the code so I'm asking how you conceptually designed the= se semantics? In particular, how many instances of a particular service wi= ll be instantiated by the engine? The init() method should only be called = once when the service is initally instantiated. Will the engine be able to= quiesce unused service instances? These are the semantics that are usuall= y derived from the container itself. Also, suppose I have some initializat= ion code that needs to be done once and can be shared among all of my servi= ce instances (singleton functionality). How can I accomplish this... for i= nstance, is there a way to tell how many instances of myself have been inst= antiated? Lastly, is there an analogous "public void destroy()" that can b= e used to release any required resources obtained by my service? > I'd like to see the following: > 1. ServiceImplInterface > public interface ServiceImplInterface { > public void init(); > public void destroy(); > } > 2. init is called when the service is instantiated... should handle one-t= ime initialization for the service. destroy is called when the service is = undeployed to release any acquired resources. > 3. can we be intelligent about the number of instances that are created f= or a particular service? if not heavily used, we need to reuse existing in= stances instead of creating additional ones. otherwise, we all should crea= te singleton services so that the system does not grow uncontrollable. > 4. if we are allowed to create multiple instances of our services, there = may be times when we want to do one-time initialization for as a whole for = all of our services instances... is there a way to determine when the last = instance is being undeployed (destroyed) so that this singleton-type of res= ource acquisition can be destroyed when the last instance is going away? --=20 This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira