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.


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.


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