aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From zoe slattery <>
Subject Re: {DISCUSS] Home for Daytrader sample leveraging Aries
Date Thu, 14 Jan 2010 08:25:26 GMT
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.

> +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 a
>>>> 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 due
>>>> 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 <> wrote:
>>>>> 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 the
>>>>> enterprise
>>>>> OSGi application programming model such as EJB support and removal of
>>>>> Geronimo specific artifacts such as the plugins.
>>>>> - Refactoring the way components gain knowledge of each other and
>>>>> interact
>>>>> to support blueprint concepts such as reference list and reference
>>>>> listeners.
>>>>> - Support for just two different persistence mechanisms - direct JDBC
>>>>> 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 for
>>>>> Daytrader
>>>>> so that I could get this running with Apache Aries.  I now have a
>>>>> 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 to
>>>>> Derby,
>>>>> and includes an Equinox assembly to run it. This is not currently in
>>>>> svn
>>>>> because I did it on my local repository under aries/trunk/samples with
>>>>> hopes
>>>>> of checking it in there.
>>>>> I think it is time to get this code to a better home and I'm currently
>>>>> thinking that aries/trunk/samples is a good place to start.  For now
>>>>> would
>>>>> check in just the version with JDBC and the equinox assembly. However,
>>>>> would extend this with other capabilities already in my sandbox for JPA
>>>>> persistence, the Aries Application packaging, etc... as these become
>>>>> 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 code under
>>>>> aries/trunk/samples.
>>>>> Here are the current discussion points and concerns as I see them:
>>>>> 1) Duplication of code between Geronimo and Aries if I check it into
>>>>> Aries.
>>>>> However, the code is already split from the JavaEE Daytrader version
>>>>> I
>>>>> doubt it would be possible to fully merge the code base and keep both
>>>>> 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 web
>>>>> container
>>>>> among other things.  It is certainly my intention that this should run
>>>>> 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.
>>>>> think moving this enterprise OSGi application version of Daytrader to
>>>>> 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 this
>>>>> version of
>>>>> Daytrader in under
>>>>> Thanks,
>>>>> Joe
>>> --
>>> Joe

View raw message