Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 51198 invoked from network); 24 Jul 2008 13:30:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 24 Jul 2008 13:30:59 -0000 Received: (qmail 3013 invoked by uid 500); 24 Jul 2008 13:30:57 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 2952 invoked by uid 500); 24 Jul 2008 13:30:57 -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 2941 invoked by uid 99); 24 Jul 2008 13:30:57 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Jul 2008 06:30:57 -0700 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 (athena.apache.org: domain of sainathdreams@gmail.com designates 209.85.142.189 as permitted sender) Received: from [209.85.142.189] (HELO ti-out-0910.google.com) (209.85.142.189) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Jul 2008 13:30:03 +0000 Received: by ti-out-0910.google.com with SMTP id b6so1584062tic.1 for ; Thu, 24 Jul 2008 06:30:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=nFmrYC6OJpsqC+f5uDyK2NbmXUzIZXLathy1s+PSss8=; b=EIGBsEo3cLSQfua5rz7hAXHfhe3FMEr7IlMpSR1fUhQ4sw4dzAXwtuD1TFlY/KIWTh EnwfpeFqWChSfAZ7luKh0k7Q/928IP2Vtn2/HxhXIUpwfZuHm0hn3U1FL+LbZlfg2afQ pUsc3XhniK3/lJ2Ey4zbkk+KUEId/de8iMSDU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=x6mxGnD7a3zX0NYwK4uA5H52sn0d/XiAE+lCqmvjxzAlUCl2jeB/YJr8Ur5XTmT1VE BmKQ7U0FkF7T0bCiIj0g0fr9k2PO3JfhOZFYx0zXO7Xm30y7f0C2QrV/3JaAdwyeATiZ v3xwlImp/1gSas8VO3P7KTCDRV9uIjrMCRIzo= Received: by 10.110.109.12 with SMTP id h12mr254428tic.34.1216906209932; Thu, 24 Jul 2008 06:30:09 -0700 (PDT) Received: by 10.110.11.12 with HTTP; Thu, 24 Jul 2008 06:30:09 -0700 (PDT) Message-ID: <435270830807240630v38fa1128va9edcf30d3123246@mail.gmail.com> Date: Thu, 24 Jul 2008 19:00:09 +0530 From: "Sainath Chowdary" To: dev@geronimo.apache.org Subject: Re: Multiple schema version support in GEP In-Reply-To: <4887D8A6.5070109@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_11838_14149945.1216906209922" References: <435270830807230519q610cad19n61f96c47e5d6c338@mail.gmail.com> <4887D8A6.5070109@gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_11838_14149945.1216906209922 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks Ted and Tim for your feedback. I agree with both of you that we cannot attempt this in trunk as next release is ahead of us in few weeks. I would be happy to work on the proposed architecture for GEP once I get back to my college. Also by that time I guess 2.1.2 would have been released. On Thu, Jul 24, 2008 at 6:49 AM, Tim McConnell wrote: > Hi Sainath, I agree with Ted as well. Your ideas seem sound but I don't > think we should attempt this in GEP trunk, which will soon be released in > conjunction with the 2.1.2 Geronimo server. As an alternative, could you > possibly work on this in the devtools sandbox ?? > > > Sainath Chowdary wrote: > >> I think that current architecture of GEP is too rigid in a way which >> produces very redundant code if we extend it for future versions of >> Geronimo. Also it is not compliant with multiple version of schemas.The UI >> elements are also somewhat implemented in a hacky way where v20 UI depends >> on v21 UI which should be the opposite. We need to introduce proper >> hierarchy levels according to schema/server versions in GEP MVC at this >> level before GEP becomes overly complicated. >> >> For this I propose we change the architecture of our JAXB model to provide >> support for multiple versions of schemas. With the help of slight >> customizations we can easily make JAXB model tailored for our purpose. The >> main task would be to create a common pool of classes between the versions >> and initializing the JAXB context properly. Assuming we support both v2.0 >> and v2.1 which respectively have geronimo-web-2.0.xsd & >> geronimo-web-2.0.1.xsd, we will create a Interface that will be implemented >> by both WebAppTypes so that in commn UI section we can directly cast to the >> interface and in version specific UI we can cast it to the particular >> version we are working in. >> >> After that we may need to refactor the code in ui plugins to utilize the >> new hierarchy levels and extra functionality added. Current architecture >> will easily achieve its bottleneck if the schema changes frequently. I find >> it this is the ideal time to reorganize the whole of GEP. >> Any comments? >> >> -- >> Thanks, >> Sainath Chowdary >> B.Tech III yr, Spring Semester >> Electronics & Communication Engg >> Indian Institute of Technology Roorkee >> > > -- > Thanks, > Tim McConnell > -- Thanks, Sainath Chowdary B.Tech III yr, Spring Semester Electronics & Communication Engg Indian Institute of Technology Roorkee ------=_Part_11838_14149945.1216906209922 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Thanks Ted and Tim for your feedback. I agree with both of you that we cannot attempt this in trunk as next release is ahead of us in few weeks.

I would be happy to work on the proposed architecture for GEP once I get back to my college. Also by that time I guess 2.1.2 would have been released.

On Thu, Jul 24, 2008 at 6:49 AM, Tim McConnell <tim.mcconne@gmail.com> wrote:
Hi Sainath, I agree with Ted as well. Your ideas seem sound but I don't think we should attempt this in GEP trunk, which will soon be released in conjunction with the 2.1.2 Geronimo server. As an alternative, could you possibly work on this in the devtools sandbox ??


Sainath Chowdary wrote:
I think that current architecture of GEP is too rigid in a way which produces very redundant code if we extend it for future versions of Geronimo. Also it is not compliant with multiple version of schemas.The UI elements are also somewhat implemented in a hacky way where v20 UI depends on v21 UI which should be the opposite. We need to introduce proper hierarchy levels according to schema/server versions in GEP MVC at this level before GEP becomes overly complicated.

For this I propose we change the architecture of our JAXB model to provide support for multiple versions of schemas. With the help of slight customizations we can easily make JAXB model tailored for our purpose. The main task would be to create a common pool of classes between the versions and initializing the JAXB context properly. Assuming we support both v2.0 and v2.1 which respectively have geronimo-web-2.0.xsd & geronimo-web-2.0.1.xsd, we will create a Interface that will be implemented by both WebAppTypes so that in commn UI section we can directly cast to the interface and in version specific UI we can cast it to the particular version we are working in.

After that we may need to refactor the code in ui plugins to utilize the new hierarchy levels and extra functionality added. Current architecture will easily achieve its bottleneck if the schema changes frequently. I find it this is the ideal time to reorganize the whole of GEP.
Any comments?

--
Thanks,
Sainath Chowdary
B.Tech III yr, Spring Semester
Electronics & Communication Engg
Indian Institute of Technology Roorkee

--
Thanks,
Tim McConnell



--
Thanks,
Sainath Chowdary
B.Tech III yr, Spring Semester
Electronics & Communication Engg
Indian Institute of Technology Roorkee
------=_Part_11838_14149945.1216906209922--