Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 29962 invoked from network); 30 Jul 2007 14:48:24 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 30 Jul 2007 14:48:24 -0000 Received: (qmail 13070 invoked by uid 500); 30 Jul 2007 14:48:23 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 13016 invoked by uid 500); 30 Jul 2007 14:48:23 -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 13005 invoked by uid 99); 30 Jul 2007 14:48:23 -0000 Received: from Unknown (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Jul 2007 07:48:23 -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 cjblythe25@gmail.com designates 209.85.162.180 as permitted sender) Received: from [209.85.162.180] (HELO el-out-1112.google.com) (209.85.162.180) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Jul 2007 14:48:19 +0000 Received: by el-out-1112.google.com with SMTP id b25so203863elf for ; Mon, 30 Jul 2007 07:47:58 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=H4IphmwZprRVcF/27BtcFfz+tNYZOsA3dSN13Tt7JqDYvlsVzHKDtmFgq/bZWUE6XhrMpDKJCI447F4tDhVGlM4PkqafQhG/Bqc47KfopxdlknTZBt+yasifqllZih2t7zXMM/wq+lWMPNfgW8p+qV1aL+BUCttML8aEPVrl6BE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=H71KdWDWV2HAfbq9paiB0IBEFF0vU7AYOpNcd6nANmp/MM5Rir6j00xK1ht9/7wpFsOo5SMjZhhVZK3uuQsqIof+Td/j0oZQKhtnkenZerC/8JMAsVyTo2K+xXssREHG1Xl41tLJsB1pVzJitlOYruIJqiihBFDkqF+YkonFsFE= Received: by 10.100.166.14 with SMTP id o14mr4627967ane.1185806878157; Mon, 30 Jul 2007 07:47:58 -0700 (PDT) Received: by 10.100.127.13 with HTTP; Mon, 30 Jul 2007 07:47:58 -0700 (PDT) Message-ID: <421012bd0707300747n667a4d23j1b6eec70620677a7@mail.gmail.com> Date: Mon, 30 Jul 2007 10:47:58 -0400 From: "Christopher Blythe" To: dev@geronimo.apache.org Subject: Re: What to do with legacy EJB 2.1 code in DayTrader? In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_33409_20211877.1185806878111" References: <421012bd0707250956g2f1bf101va56796845c707fe@mail.gmail.com> <2B4273A6-0848-4FEB-84C0-ABECBC4EDB47@iq80.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_33409_20211877.1185806878111 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I like having the 2.1 code around as well for the same reasons you stated. I just don't like the idea of having the two implementations inter-mingled in the same ear/jar. It makes DayTrader's usefulness as a code sample for developers a lot harder to swallow. I also have a hard time believing that there are going to be a lot of production applications out there that use both EJB 2.1 and 3.0 components in the same package. So, my original thinking was to, use DT 1.2 as the J2EE 1.4 based sample and DT 2.0 as the EE 5 based sample. Another option I just thought of is to refactor the packaging such that two ejb jar files can be created, one for the EJB 2.1 legacy code and another for the new EJB 3.0 components. The pom files could then be modified to create two ear files. Thoughts? On 7/29/07, Kevan Miller wrote: > > > On Jul 27, 2007, at 3:31 PM, Dain Sundstrom wrote: > > > I'd like to see the 2.1 code kept around so we can compare base EJB > > performance against other servers. There is going to be legacy > > code for a long time and this tool is our only way to see how > > legacy code performs on our server. > > > > -dain > > > > On Jul 25, 2007, at 9:56 AM, Christopher Blythe wrote: > > > >> All, > >> > >> Given Geronimo 2.0 and DayTrader 2.0's focus on Java EE 5, I was > >> wondering if it made sense to remove the old EJB 2.1 code? To be > >> quite honest, I am torn. One one side, it would be nice to have > >> both the EJB 2.1 and 3.0 impls at the same time for comparison > >> purposes. However, keeping the old stuff around seems to hide the > >> fact that 3.0 is supposed to be easier to work with and develop. > >> > >> Here are some options along with my own arguments for each... > >> > >> 1) Remove the old EJB 2.1 modes and make DayTrader 2.0 EJB 3 only > >> - highlights the advantages of EJB 3.0 (less DDs, etc.) > >> - makes the packaging and various runtime modes less confusing > >> - can use the DayTrader 1.2 code for comparisons between EJB > >> 2.1 and 3.0 > >> - EJB 2.1 mode never worked under load to begin with due to > >> consistency issues > >> > >> 2) Leave 2.1 code in there for now and phase out in a DayTrader 2.X > >> - comparisons can be done using a single ear > >> - DT 2.x could be spun up immediately > >> > >> Now that I think about it, I think I'm swaying more towards option > >> 1. However, given the time constraints to get 2.0 out the door, > >> I'm not sure if 1 is realistic. > > I like having 2.1 code around, also. I was just using it to identify > JPA/CMP/Entity problems, yesterday... > > One of the strengths of DayTrader is the breadth of technologies that > it can drive. IMO, it's not intended to be an exemplar of how simple > it is to write a Java EE 5 applications... I'd be hesitant to lose > the flexibility that Daytrader gives us. If this flexibility is > hurting our ability to gather valid performance results or cannot be > reasonably maintained, then I'm all ears. > > --kevan > -- "I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may." - Tyler Durden ------=_Part_33409_20211877.1185806878111 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I like having the 2.1 code around as well for the same reasons you stated. I just don't like the idea of having the two implementations inter-mingled in the same ear/jar. It makes DayTrader's usefulness as a code sample for developers a lot harder to swallow. I also have a hard time believing that there are going to be a lot of production applications out there that use both EJB 2.1 and 3.0 components in the same package.

So, my original thinking was to, use DT 1.2 as the J2EE 1.4 based sample and DT 2.0 as the EE 5 based sample.

Another option I just thought of is to refactor the packaging such that two ejb jar files can be created, one for the EJB 2.1 legacy code and another for the new EJB 3.0 components. The pom files could then be modified to create two ear files.

Thoughts?

On 7/29/07, Kevan Miller <kevan.miller@gmail.com> wrote:

On Jul 27, 2007, at 3:31 PM, Dain Sundstrom wrote:

> I'd like to see the 2.1 code kept around so we can compare base EJB
> performance against other servers.  There is going to be legacy
> code for a long time and this tool is our only way to see how
> legacy code performs on our server.
>
> -dain
>
> On Jul 25, 2007, at 9:56 AM, Christopher Blythe wrote:
>
>> All,
>>
>> Given Geronimo 2.0 and DayTrader 2.0 's focus on Java EE 5, I was
>> wondering if it made sense to remove the old EJB 2.1 code? To be
>> quite honest, I am torn. One one side, it would be nice to have
>> both the EJB 2.1 and 3.0 impls at the same time for comparison
>> purposes. However, keeping the old stuff around seems to hide the
>> fact that 3.0 is supposed to be easier to work with and develop.
>>
>> Here are some options along with my own arguments for each...
>>
>> 1) Remove the old EJB 2.1 modes and make DayTrader 2.0 EJB 3 only
>>     - highlights the advantages of EJB 3.0 (less DDs, etc.)
>>     - makes the packaging and various runtime modes less confusing
>>     - can use the DayTrader 1.2 code for comparisons between EJB
>> 2.1 and 3.0
>>     - EJB 2.1 mode never worked under load to begin with due to
>> consistency issues
>>
>> 2) Leave 2.1 code in there for now and phase out in a DayTrader 2.X
>>     - comparisons can be done using a single ear
>>     - DT 2.x could be spun up immediately
>>
>> Now that I think about it, I think I'm swaying more towards option
>> 1. However, given the time constraints to get 2.0 out  the door,
>> I'm not sure if 1 is realistic.

I like having 2.1 code around, also. I was just using it to identify
JPA/CMP/Entity problems, yesterday...

One of the strengths of DayTrader is the breadth of technologies that
it can drive. IMO, it's not intended to be an exemplar of how simple
it is to write a Java EE 5 applications... I'd be hesitant to lose
the flexibility that Daytrader gives us. If this flexibility is
hurting our ability to gather valid performance results or cannot be
reasonably maintained, then I'm all ears.

--kevan



--
"I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may." - Tyler Durden ------=_Part_33409_20211877.1185806878111--