Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 87928 invoked from network); 7 Dec 2006 23:51:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 Dec 2006 23:51:54 -0000 Received: (qmail 44022 invoked by uid 500); 7 Dec 2006 23:51:45 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 43971 invoked by uid 500); 7 Dec 2006 23:51: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 43955 invoked by uid 99); 7 Dec 2006 23:51:43 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 Dec 2006 15:51:43 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of sppatel2@gmail.com designates 66.249.82.239 as permitted sender) Received: from [66.249.82.239] (HELO wx-out-0506.google.com) (66.249.82.239) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 Dec 2006 15:51:06 -0800 Received: by wx-out-0506.google.com with SMTP id s18so611978wxc for ; Thu, 07 Dec 2006 15:50:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:mime-version:to:message-id:content-type:from:subject:date:x-mailer; b=U2YoVqpX9F3zmpljSpDLH31ajEC5FWTWpCklUdITK8hcQNouqp7NksczDrgCxlLuyDDbLZSatcPtnoOnc1eb2NvOV1NCUA2NWANaGy0h/oJSTRRKjfcaC+R22D7xTP9hpBfuscDaOV1Tzk5rxibyA5il2AzvuteWak64TKoWavU= Received: by 10.70.99.9 with SMTP id w9mr4681912wxb.1165535426220; Thu, 07 Dec 2006 15:50:26 -0800 (PST) Received: from ?192.168.1.101? ( [24.163.114.108]) by mx.google.com with ESMTP id i17sm1422303wxd.2006.12.07.15.50.25; Thu, 07 Dec 2006 15:50:25 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) To: dev@geronimo.apache.org Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-7-397165658 From: Sachin Patel Subject: Need patch review.. Builders to use DeployableModule Interface Date: Thu, 7 Dec 2006 18:50:42 -0500 X-Mailer: Apple Mail (2.752.3) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-7-397165658 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I've attached a patch http://issues.apache.org/jira/browse/ GERONIMO-2638 that provides the changes from our builders use of JarFile to a new interface DeployableModule. Since 1.2 is currently less disruptive, I've created a patch that can be applied to 1.2 and eventually I'll port it to trunk. I did the changes in a way so that all the builders don't have to change at once and the migration can be done incrementally. Thus the use of the "temporary" classes, ModuleBuilder2, ConfigurationBuilder2, and their abstract impls. The current patch only changes the EARConfigBuilder and the WebModuleBuilders (minus WebServices). I want to go ahead and get this out so I can get input prior to migrating the rest of the builders. So please provide your comments, concerns, feedback. In a nutshell, the basic flow behind this change is the following.. (1) A deployableModuleType (gbean) can be set now in the DeploymentManager by the client (eclipse for example) (2) Given the artifact to deploy, (previously a JarFile), a new DeployableModule instance will be created through the DeployableModuleFactory class, passing the the artifact, where its a JarFile or in the eclipse case, an xml file describing the application and where all of its resources, jars, classes reside. (3) Now the builders will now be passed around this instance of DeployableModule, rather then the JarFile and the builders will process the artifact, when possible, using the DeployableModule interface. And basically thats it. This allows Geronimo to build the configuration from any directory structure, and no longer has to conform to a J2EE archive structure and the copy of a resource in an IDE is the copy that is running. It is completley pluggable and you can easily provide support for an IDE or even a Maven project structure. The only thing I don't like is when you're dealing with a JarFile (the primary case outside of an IDE). I'm creating a wrapper around the Jar using the DeployableModule implementation JarDeployable. The problem is that whenever you're processing the JarEntries, you can't use the interface and have to call.. if(deployable.isArchive()) { JarFile jar = deployable.getJarFile() //process the jar } else { //use the interface } There are only a few cases where we're travesing through the entries of a Jar, so I'm not sure if people think this is a big deal or a huge annoyance having to deal with 2 cases. Please review as it would be nice to get this into M1. If you have any suggestions on how we can improve the interface, I would love to hear your input as I just threw this interface together a while ago and I'm sure we can improve on it. Thanks. -sachin --Apple-Mail-7-397165658 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 I've attached a patch http://issues.= apache.org/jira/browse/GERONIMO-2638=A0that provides the = changes from our builders use of JarFile to a new interface = DeployableModule.=A0 Since 1.2 is currently less disruptive, I've = created a patch that can be applied to 1.2 and eventually I'll port it = to trunk.=A0 I did the changes in a way so that all the builders don't = have to change at once and the migration can be done incrementally.=A0 = Thus the use of the "temporary" classes, ModuleBuilder2, = ConfigurationBuilder2, and their abstract impls.=A0 The current patch = only changes the EARConfigBuilder and the WebModuleBuilders (minus = WebServices).=A0 I want to go ahead and get this out so I can get input = prior to migrating the rest of the builders.=A0 So please provide your = comments, concerns, feedback.

In a nutshell, the basic = flow behind this change is the following..

(1) A deployableModuleType = (gbean) can be set now in the DeploymentManager by the client (eclipse = for example)
(2) Given the artifact to deploy, (previously a = JarFile), a new DeployableModule instance will be created through the = DeployableModuleFactory class, passing the the artifact, where its a = JarFile or in the eclipse case, an xml file describing the application = and where all of its resources, jars, classes reside.
(3) Now = the builders will now be passed around this instance of = DeployableModule, rather then the JarFile and the builders will process = the artifact, when possible, using the DeployableModule = interface.

And = basically thats it.=A0 This allows Geronimo to build the configuration = from any directory structure, and no longer has to conform to a J2EE = archive structure and the copy of a resource in an IDE is the copy that = is running.=A0 It is completley pluggable and you can easily provide = support for an IDE or even a Maven project structure.

The only thing I don't like = is when you're dealing with a JarFile (the primary case outside of an = IDE).=A0 I'm creating a wrapper around the Jar using the = DeployableModule implementation JarDeployable.=A0 The problem is that = whenever you're processing the JarEntries, you can't use the interface = and have to call..

if(deployable.isArchive()) = {
= JarFile jar =3D deployable.getJarFile()
//process = the jar
} else {
//use the = interface
}

There are only a few cases = where we're travesing through the entries of a Jar, so I'm not sure if = people think this is a big deal or a huge annoyance having to deal with = 2 cases.

Please= review as it would be nice to get this into M1.=A0 If you have any = suggestions on how we can improve the interface, I would love to hear = your input as I just threw this interface=A0together a while ago and I'm = sure we can improve on it.

Thanks.

=

= --Apple-Mail-7-397165658--