Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 58452 invoked from network); 4 Apr 2006 14:08:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 4 Apr 2006 14:08:48 -0000 Received: (qmail 62634 invoked by uid 500); 4 Apr 2006 14:08:44 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 62587 invoked by uid 500); 4 Apr 2006 14:08:44 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 62576 invoked by uid 99); 4 Apr 2006 14:08:44 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Apr 2006 07:08:44 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of ammulder@gmail.com designates 64.233.166.176 as permitted sender) Received: from [64.233.166.176] (HELO pproxy.gmail.com) (64.233.166.176) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Apr 2006 07:08:43 -0700 Received: by pproxy.gmail.com with SMTP id e30so456955pya for ; Tue, 04 Apr 2006 07:08:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HJ+T8C+mQsdlKNtPzYhYNjlikQP8R862Nn44Pm58WMcDjvmtHJcTHeOufjd7q2lmXzi9gIimzH3X7eO8LCZ5miAVPVV7BiStiC1CSuopqdTm6pSqlGGNjbri+OOy+YHFVXSMJXt97hlELk5BrlTwWEOY+u3bxKOV7qfqlbEnmrE= Received: by 10.35.60.15 with SMTP id n15mr412287pyk; Tue, 04 Apr 2006 07:08:21 -0700 (PDT) Received: by 10.35.116.1 with HTTP; Tue, 4 Apr 2006 07:08:21 -0700 (PDT) Message-ID: <74e15baa0604040708u366aedeev15da7ffc2ee328d2@mail.gmail.com> Date: Tue, 4 Apr 2006 10:08:21 -0400 From: "Aaron Mulder" Sender: ammulder@gmail.com To: dev@geronimo.apache.org Subject: Re: ServiceMix integration In-Reply-To: <44322660.8060102@worldonline.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <44322660.8060102@worldonline.fr> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Guillaume, You're right that there's generally no server-wide JNDI context. It's possible to look up any resource in the server at runtime using Geronimo-specific APIs (such as Kernel.listGBeans, or using the JSR-77 management APIs). For J2EE apps, the standard practice leans towards binding everything at deployment time, so we have a deployment descriptor that maps the declared resources to actual resources in the server during deployment. Then we create the component-specific JNDI space during deployment containing the resources to be made avaliable to the component, because that's what J2EE dictates. But it's not the only possible way things could work. I'm having trouble wrapping my head around how resources should normally work in ServiceMix. Is there some place in jbi.xml or other standard JBI deployment information for, say, a service unit to declare that it needs resources like a JMS connection factory and destination? If not, how is ServiceMix/Geronimo supposed to know what resources to provide? Is there just an assumption that a global JNDI namespace will be present containing every resource in the server and each component can look up whatever it wants to? Thanks, Aaron On 4/4/06, Guillaume Nodet wrote: > Thanks to dain and djencks advises, I have began to write a real > ServiceMix integration for Geronimo. > However I am facing a number of problems. > > The problem is that the JBI spec needs some things to be done when > undeploying jbi artifacts so I will be in need of an event fired before > undeployment (and not after as this is the current case). Let me > explain the use case for this. > The JBI container is a server (like a web server or EJB server): it > accepts three kind of deployment artifacts: component, shared libraries > and service assemblies. A shared library is a collection of jars to be > added to the classpath of a component. A component is also a container, > like a BPEL engine for example. A service assembly is a package > containing service units. These service units are given to a target > component upon deployment. A service unit could a BPEL process. > When deploying a BPEL process onto a BPEL engine, the engine may have to > store the process in a database at deployment time and remove the clean > the database when undeploying the service unit. The JBI spec has all > the needed interfaces to perform these deployment / undeployment steps. > The only problem is that I have not found any way to know when a > configuration is being undeployed. > Looking at the kernel, it seems it should be quite easy to do, so I > think I will raise a JIRA for that and attach a patch at a later time. > > The next problem, which is IMHO more important, is how to access managed > resources. In the previous BPEL engine example, the component has to > access a database. A JMS component would access a JMS connection > factory. These resources should be accessed via JNDI. I have browsed > the naming / deployer code these past days and AFAIK, there is no > server-wide JNDI context. When a web app is deployed, a specific JNDI > context is created (and bound to the thread with interceptors), that > includes all the bindings referenced in the web deployment descriptor. > This leads me to think that I have to create a geronimo-jbi.xml > deployment descriptor which will contain resource references and / or > additional gbeans for the configuration. > I fear this will lead to another problem, which is the fact that these > resources are usually deployed inside an EAR and JBI artifacts can not... > So the main questions is: did I miss something ? Is there any easier way > to access server-wide resources or do I really have to create a specific > deployment plan of some kind ? > > Cheers, > Guillaume Nodet > > >