Re: What to do with legacy EJB 2.1 code in DayTrader?
On Jul 30, 2007, at 10:47 AM, Christopher Blythe wrote: 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? From a usage perspective, it's great to have a single ear with multiple, selectable modes. If that's impractical, I'm ok with multiple ears. --kevan
Re: What to do with legacy EJB 2.1 code in DayTrader?
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 [EMAIL PROTECTED] 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
Re: What to do with legacy EJB 2.1 code in DayTrader?
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
Re: What to do with legacy EJB 2.1 code in DayTrader?
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. Thoughts? Thanks... Chris -- I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may. - Tyler Durden
What to do with legacy EJB 2.1 code in DayTrader?
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. Thoughts? Thanks... Chris -- I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may. - Tyler Durden
Re: What to do with legacy EJB 2.1 code in DayTrader?
+1 for option #1 - remove the old EJB 2.1 code. -Donald 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. Thoughts? Thanks... Chris -- I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may. - Tyler Durden smime.p7s Description: S/MIME Cryptographic Signature
Re: What to do with legacy EJB 2.1 code in DayTrader?
On Jul 25, 2007, at 12:56 PM, Christopher Blythe wrote: I think I'm swaying more towards option 1. Ok, I like that option. I wouldn't worry about daytrader release relative to Geronimo if that was your concern about time. If we rlelease DT 2.0 a month later it won't kill us. We haven't really talked about a release for it as we've really only been using it for validation of G.
