geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: {DISCUSS] Home for Daytrader sample leveraging Aries
Date Thu, 14 Jan 2010 14:10:39 GMT
It seems there is consensus to introduce this Aries enabled version of 
Daytrader into Apache Aries for now.  I'll add it under the top level 
pom.  It appears that a rename is also in order.  I'd do that as step 
two which will leave a little better record of the history of the code.

Some recent rework of the sample has created some new issues that I need 
to resolve - but I'll hopefully be checking it in very soon.

Thanks for all the feedback!


Alasdair Nottingham wrote:
> I think you should add the samples into the top level pom to ensure
> they are built. We can worry about build time later.
> Alasdair
> 2010/1/14 zoe slattery <>:
>> Hi - As far as I understand it the samples are not building as part of the
>> regular Hudson build at the moment, they are certainly not listed as a
>> module in the top level pom. I hadn't added them because I was slightly
>> concerned about the time it would take to build and assemble them as part of
>> the regular build. However, I would like to have them building regularly and
>> used as tests somehow, adding a very big sample to them right now doesn't
>> seem quite the right thing to do.
>> I would really like to have the daytrader code in Aries and think it would
>> be helpful to have a fairly complex application. So, my preference would be
>> not to put daytrader  in samples (at least to start with), it sounds (I
>> don't know the code) big enough to merit a separate module then if there are
>> problems because of its complexity we can easily separate it out.
>> Zoe
>>> +1 to putting it under samples at least for now!
>>> Jeremy
>>> 2010/1/12 Alasdair Nottingham <>:
>>>> I would stick with putting it under samples for now. We can always move
>>>> it
>>>> later and we have not discussed releases yet, so we cannot know what
>>>> implications there are for release if it is under samples.
>>>> Alasdair
>>>> On 12 Jan 2010, at 19:17, Joe Bohn <> wrote:
>>>>> Good points Lin.  Perhaps we should consider another location under
>>>>> Aries
>>>>> trunk ... or we can check it in initially under trunk/samples and move
>>>>> it if
>>>>> it proves to be an issue.
>>>>> Regarding the itest ... sure, we should give that some consideration.
>>>>> I'd
>>>>> personally have to understand the current itests better and the
>>>>> capabilities
>>>>> before I could assert that daytrader could be added in for additional
>>>>> testing.
>>>>> Joe
>>>>> Lin Sun wrote:
>>>>>> Hi Joe,
>>>>>> I think it makes sense to have the new daytrader in apache aries.
>>>>>> Just wondering if you want to have it under trunk/samples or have
>>>>>> separate directory for daytrader so that you could release daytrader
>>>>>> separately like daytrader in Geronimo.   Another advantage of doing
>>>>>> this separately is that people can easily build the samples without
>>>>>> building daytrader which i know sometimes we have trouble to build
>>>>>> to its complexity.
>>>>>> Also wondering if it is possible to use the daytrader sample as part
>>>>>> of our itest after moving it over to apache aries.
>>>>>> Thanks
>>>>>> Lin
>>>>>> On Mon, Jan 11, 2010 at 2:57 PM, Joe Bohn <>
>>>>>>> Greetings all,
>>>>>>> I've been working on a version of the Geronimo Daytrader performance
>>>>>>> benchmark to leverage the enterprise OSGi application programming
>>>>>>> model.
>>>>>>> I've been doing this work in my sandbox under Apache Geronimo
>>>>>>> ( with
the most
>>>>>>> recent changes under daytrader-bp-new).
>>>>>>> I'd like to find a more permanent location for this work and
get it
>>>>>>> out
>>>>>>> of
>>>>>>> my sandbox.
>>>>>>> Here is a brief description of what I have thus far in sandbox:
>>>>>>> - A restructured Daytrader to support an enterprise OSGi application
>>>>>>> programming model including blueprint, web container, jndi, jpa,
>>>>>>> etc...
>>>>>>> - To further support this programming model I have also reorganized
>>>>>>> the
>>>>>>> classes, packages, and bundles.
>>>>>>> - Simplification and removal of content not yet available in
>>>>>>> enterprise
>>>>>>> OSGi application programming model such as EJB support and removal
>>>>>>> Geronimo specific artifacts such as the plugins.
>>>>>>> - Refactoring the way components gain knowledge of each other
>>>>>>> interact
>>>>>>> to support blueprint concepts such as reference list and reference
>>>>>>> listeners.
>>>>>>> - Support for just two different persistence mechanisms - direct
>>>>>>> and
>>>>>>> direct JPA which are currently included in the enterprise OSGi
>>>>>>> application
>>>>>>> programming model.
>>>>>>> - packaging using the Aries Application concepts.
>>>>>>> After seeing the recently introduced Apache Aries Blog Sample
and its
>>>>>>> assembly for Equinox it encouraged me to do something similar
>>>>>>> Daytrader
>>>>>>> so that I could get this running with Apache Aries.  I now have
>>>>>>> further
>>>>>>> subset of my sandbox work that could be added as a peer to the
>>>>>>> blog-sample
>>>>>>> which includes just the JDBC persistence mechanism, is hard-wired
>>>>>>> Derby,
>>>>>>> and includes an Equinox assembly to run it. This is not currently
>>>>>>> any
>>>>>>> svn
>>>>>>> because I did it on my local repository under aries/trunk/samples
>>>>>>> hopes
>>>>>>> of checking it in there.
>>>>>>> I think it is time to get this code to a better home and I'm
>>>>>>> thinking that aries/trunk/samples is a good place to start. 
For now I
>>>>>>> would
>>>>>>> check in just the version with JDBC and the equinox assembly.
>>>>>>> I
>>>>>>> would extend this with other capabilities already in my sandbox
>>>>>>> JPA
>>>>>>> persistence, the Aries Application packaging, etc... as these
>>>>>>> available in Aries.
>>>>>>> I'm interested if others agree with this approach, if it seems
like a
>>>>>>> worthwhile endeavor, and if it is acceptable to include this
>>>>>>> under
>>>>>>> aries/trunk/samples.
>>>>>>> Here are the current discussion points and concerns as I see
>>>>>>> 1) Duplication of code between Geronimo and Aries if I check
it into
>>>>>>> Aries.
>>>>>>> However, the code is already split from the JavaEE Daytrader
>>>>>>> and
>>>>>>> I
>>>>>>> doubt it would be possible to fully merge the code base and keep
>>>>>>> the
>>>>>>> JavaEE and Aries versions working from a common code base without
>>>>>>> cluttering
>>>>>>> up the code with environment checks.   So, even if we keep it
all in
>>>>>>> Geronimo I think we will still end up with multiple code streams.
>>>>>>> 2) The Equinox assembly version for DayTrader currently doesn't
>>>>>>> exploit
>>>>>>> anything directly in Apache Geronimo.  It depends upon the pax
>>>>>>> container
>>>>>>> among other things.  It is certainly my intention that this should
>>>>>>> on
>>>>>>> Geronimo when Geronimo supports osgi rfc 66 among other things.
>>>>>>>  However
>>>>>>> it
>>>>>>> seems strange to include this in Geronimo at this point in time.
>>>>>>> 3) Daytrader has always supported running in multiple web containers.
>>>>>>>  I
>>>>>>> think moving this enterprise OSGi application version of Daytrader
>>>>>>> Aries
>>>>>>> further supports this goal and ensures that it won't become too
>>>>>>> tightly
>>>>>>> coupled to Geronimo.
>>>>>>> My apologies for the length of this description.  Please let
me know
>>>>>>> your
>>>>>>> thoughts - especially if you have any concerns with checking
>>>>>>> version of
>>>>>>> Daytrader in under
>>>>>>> Thanks,
>>>>>>> Joe
>>>>> --
>>>>> Joe


View raw message