Return-Path: X-Original-To: apmail-commons-user-archive@www.apache.org Delivered-To: apmail-commons-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id EEBD410915 for ; Sat, 12 Oct 2013 09:19:04 +0000 (UTC) Received: (qmail 27308 invoked by uid 500); 12 Oct 2013 09:18:55 -0000 Delivered-To: apmail-commons-user-archive@commons.apache.org Received: (qmail 27207 invoked by uid 500); 12 Oct 2013 09:18:43 -0000 Mailing-List: contact user-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Users List" Delivered-To: mailing list user@commons.apache.org Received: (qmail 27197 invoked by uid 99); 12 Oct 2013 09:18:39 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 12 Oct 2013 09:18:39 +0000 Received: from localhost (HELO mail-we0-f173.google.com) (127.0.0.1) (smtp-auth username britter, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Sat, 12 Oct 2013 09:18:39 +0000 Received: by mail-we0-f173.google.com with SMTP id u57so5138371wes.18 for ; Sat, 12 Oct 2013 02:18:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=xzHzxhot+0oHxvYMElbPN0IURGDcBfGWnW+w1sCWFQQ=; b=Zcaeu+BV6KxCH6N33IvX+gHjplcEQjJ3PbBb8zI4OV5OLTXLu5J2bsxXpT9djAAMsf PIv/h8cHMliuEv1WJmTv1TtEp0q4U4XCuwNcYJxq0yI1Rrz1h1haaN2J0c2qnLtghoNj J5Z+AatphVToetitgpn0uyRQmzRfQCP1EspaaDtpX2gSWdnb6KTdJERc4VSYyY8sWBlr Ftu5gKfdw7na/u+KW/jxtZvWQo7QHscFQHcfBUUX5H8iUM7XqT7RJ68m3zh0XZAn84g1 2Q1Gx/gCpim/vHrKPL0NFbrK0s4UnD1x3olTvfmiWkkQNYxz+3/blgkHOQMZssettTkb 5gog== MIME-Version: 1.0 X-Received: by 10.180.77.82 with SMTP id q18mr6550090wiw.7.1381569517184; Sat, 12 Oct 2013 02:18:37 -0700 (PDT) Received: by 10.194.190.136 with HTTP; Sat, 12 Oct 2013 02:18:37 -0700 (PDT) In-Reply-To: <141aa236d16.-1805542011225357664.-544792274832952446@zohocorp.com> References: <141a6aeef01.-992964900450943755.8799981357426869074@zohocorp.com> <141aa236d16.-1805542011225357664.-544792274832952446@zohocorp.com> Date: Sat, 12 Oct 2013 11:18:37 +0200 Message-ID: Subject: Re: Chain Configuration From: Benedikt Ritter To: Commons Users List Content-Type: multipart/alternative; boundary=f46d043d679f4df13e04e887b8b1 --f46d043d679f4df13e04e887b8b1 Content-Type: text/plain; charset=ISO-8859-1 Hi Jagan, sorry I don't understand what you mean by "retained CatalogFactory instance in our backend code". Can you explain? Benedikt 2013/10/12 Jagan Ranganathan > Hi, > > Thanks for your response. We retained CatalogFactory instance in our > backend code where we parsed the chain config xml. You see any issues with > this? > > > Regards, > Jagan > > ---- On Fri, 11 Oct 2013 14:52:25 +0530 Benedikt > Ritter<britter@apache.org> wrote ---- > > > Hi Jagan, > > as far as I know, no there isn't... We know this is a flaw in chain and we > intended to fix it for chain2 (which is in the current trunk of chain). But > currently there is nobody who really has the time make chain2 ready for a > release. Simone Tripodi was working on it and he intended to implement the > configuration module using modello [1]. But that seems to be blocked until > a new modello release hits the road... > > Benedikt > > [1] http://modello.codehaus.org > > > 2013/10/11 Jagan Ranganathan <jagan@zohocorp.com> > > > Hi, > > > > We are trying to use Chain Of Responsibility pattern in the server > side. > > We have defined our chain+commands in an xml and are parsing it via > > ConfigParser. > > > > > > But we face a problem with getting Catalog via > > CatalogFactoryBase.getInstance().getCatalog(catalogName) call.Looks > like it > > has got some ClassLoader specific loading. So if we have initialized > in > > some web context, the Catalog is not present in other context - > different > > ClassLoader. > > Is there anyway we can remove this ClassLoader level dependency or is > > there any other way of loading the chain configuration for server side > > usage? > > /** * &lt;p&gt;Return the singleton {@link CatalogFactory} > instance > > * for the relevant > &lt;code&gt;ClassLoader&lt;/code&gt;. For > > applications > > * that use a thread context class loader (such as web applications > > * running inside a servet container), this will return a separate > > * instance for each application, even if this class is loaded from > > * a shared parent class loader.&lt;/p&gt; > > * > > * @return the per-application singleton instance of {@link > > CatalogFactory} > > */ > > public static CatalogFactory getInstance() { > > > > > > CatalogFactory factory = null; > > ClassLoader cl = getClassLoader(); > > synchronized (factories) { > > factory = (CatalogFactory) factories.get(cl); > > if (factory == null) { > > factory = new CatalogFactoryBase(); > > factories.put(cl, factory); > > } > > } > > return factory; > > > > > > } > > > > Regards, > > Jagan > > > > > > > > > > > -- > http://people.apache.org/~britter/ > http://www.systemoutprintln.de/ > http://twitter.com/BenediktRitter > http://github.com/britter > > > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter --f46d043d679f4df13e04e887b8b1--