Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 68819 invoked from network); 29 May 2006 03:09:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 29 May 2006 03:09:06 -0000 Received: (qmail 91727 invoked by uid 500); 29 May 2006 03:09:00 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 91675 invoked by uid 500); 29 May 2006 03:09:00 -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 91656 invoked by uid 99); 29 May 2006 03:09:00 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 28 May 2006 20:09:00 -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.162.205 as permitted sender) Received: from [64.233.162.205] (HELO nz-out-0102.google.com) (64.233.162.205) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 28 May 2006 20:08:59 -0700 Received: by nz-out-0102.google.com with SMTP id j2so535884nzf for ; Sun, 28 May 2006 20:08:38 -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:x-google-sender-auth; b=gpSAmstCi4Pnms6kltekYV1l73PQb+TrqVZUC2qKeyq4QjVQpMlChm11/yUH4B5ImHTH6X00UL0VjdYI5duddPHNBZeIXIIt/wsGnW4wcHiJxoomH1kZaAeUW+NrgvPlgNtnhDGC6EwlhvNO/j0I+g13DKA2+vvz8h+B0S910us= Received: by 10.65.74.15 with SMTP id b15mr122633qbl; Sun, 28 May 2006 20:08:38 -0700 (PDT) Received: by 10.65.176.15 with HTTP; Sun, 28 May 2006 20:08:38 -0700 (PDT) Message-ID: <74e15baa0605282008r35b4175dhad36e7df9b7658ba@mail.gmail.com> Date: Sun, 28 May 2006 23:08:38 -0400 From: "Aaron Mulder" Sender: ammulder@gmail.com To: dev@geronimo.apache.org Subject: Re: Support for different modules types in EAR In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <74e15baa0605281005t2c2967d3q756eadee58d768ba@mail.gmail.com> <447A19BF.4020509@worldonline.fr> X-Google-Sender-Auth: 4312d9a920c7263f X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Every app server has a proprietary deployment plan for each module type (e.g. weblogic.xml, jboss-web.xml, geronimo-web.xml, etc., etc., etc.) or other means of specifying server-specific information (I believe earlier WebSphere servers stored everything in a database instead of an XML file). As far as I know, the spec doesn't specifically say you can or can't add new modules to a J2EE application. It wouldn't be portable to another server, of course, though you can do similar things in some of them. As for ServiceMix, to address one of the points, there's a Geronimo thread pool GBean so any ServiceMix integration can (and IMHO should) take a thread pool reference and thereby use Geronimo managed threads. As for JNDI, we do have global JNDI on the long-term plan, but we may want to plan to use a Geronimo/ServiceMix deployment plan with a local JNDI space with resource/EJB references for now. (This will also be necessary to let you specify a module name for a ServiceMix deployment, and to redeploy modules with a deployment plan.) Though I guess we'll want to be able to reference ServiceMix endpoints from J2EE apps as well as vice versa, so we should think about how to do that too. Thanks, Aaron On 5/28/06, Mohammed Nour wrote: > On 5/29/06, Guillaume Nodet wrote: > > I fully agree to support that. > > > > EAR is by definition an application, and I think that every deployable > > feature in Geronimo should be able to deploy within an EAR. > > Especially for ServiceMix, I think this would be a great addition: > > ServiceMix is an integration bus and it should be able to completely > > integrate with Geronimo, but some limitations are difficult to work > > around, the main ones being: > > * the lack of global JNDI, > > * deployment along with other J2EE resources (which would be solved by > > deploying JBI applications within an EAR) > > * use of unmanaged threads wrt to transactions and J2EE resources (you > > have to be fully integrated into Geronimo so that you can initialize th= e > > necessary thread local variables containing the contexts for various > > Geronimo layers when these contexts could easily be created when first > > used in a non-initialized thread) > > > > AFAIK, Geronimo main goal so far has been to be fully J2EE compliant, > > > > I want to ask, is it compliant to J2EE to have a proprietary application > deployment descriptor specific to a certain app-server ? and adding new a= nd > specific declarations to it ? > > > > but all these points fall into the ease of use category and could / > > should be addressed. > > > > Cheers, > > Guillaume Nodet > > > > > > Aaron Mulder wrote: > > > > > Any objections to supporting different module types (such as Geronimo > > > service JARs or future Spring or ServiceMix JARs) within an EAR? For > > > example, this would let you create an EAR with a normal EJB JAR, a > > > normal web app WAR, and a Geronimo service JAR containing GBeans used > > > by the EJBs or web app (or that just run when the app runs). > > > > > > To do this, I figure we'd just let you specify additional modules in > > > the geronimo-application.xml, even if you're not going to provide a > > > plan for them. So it would be something like this: > > > > > > application.xml > > > > > > > > > foo.jar > > > ... > > > > > > > > > geronimo-application.xml > > > > > > > > > > > > bar.jar > > > > > > > > > > > > Where a plan like this indicates that there are no overrides for the > > > EJB or Web app, but we're adding another module, bar.jar, with > > > unspecified type. That should be OK since during deployment we ask > > > all the config builders whether they can handle the specified module, > > > so we'll figure out whether we can handle it, and if so, what type of > > > module it is (based on what deployment descriptors / plans it > > > contains). > > > > > > Thanks, > > > Aaron > > > > > > > > > >