You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Joe Bohn <jo...@gmail.com> on 2010/01/11 20:57:41 UTC
{DISCUSS] Home for Daytrader sample leveraging Aries
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
(https://svn.apache.org/repos/asf/geronimo/sandbox/jbohn 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 any 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 I
would check in just the version with JDBC and the equinox assembly.
However, I 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 and 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. I
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
https://svn.apache.org/repos/asf/incubator/aries/trunk/samples
Thanks,
Joe
Re: {DISCUSS] Home for Daytrader sample leveraging Aries
Posted by Alasdair Nottingham <no...@apache.org>.
If a new name is really important I suggest AriesTrader.
Alasdair
2010/1/13 Kevan Miller <ke...@gmail.com>:
>
> On Jan 12, 2010, at 2:57 PM, David Jencks wrote:
>
>> Daytrader has a long history of insufficient maintenance and ad-hoc changes to suit the demands of the moment, followed by no cleanup of all the broken edges. IMO having an aries version of daytrader, the latest hot thing, will mean that the ee version will be completely dead. I don't think this is desirable. However, I'm not likely to work on any version of daytrader in the forseeable future.
>
> I don't disagree with your history of DayTrader. However, I doubt that the EE version dies, at least not right away. There is, and will continue to be a need for samples on both programming models. Assuming that's true, I think it's potentially confusing to end up with two different applications called "DayTrader". So, I'm wondering if there should be some separation, naming-wise...
>
> --kevan
--
Alasdair Nottingham
not@apache.org
Re: {DISCUSS] Home for Daytrader sample leveraging Aries
Posted by Kevan Miller <ke...@gmail.com>.
On Jan 12, 2010, at 2:57 PM, David Jencks wrote:
> Daytrader has a long history of insufficient maintenance and ad-hoc changes to suit the demands of the moment, followed by no cleanup of all the broken edges. IMO having an aries version of daytrader, the latest hot thing, will mean that the ee version will be completely dead. I don't think this is desirable. However, I'm not likely to work on any version of daytrader in the forseeable future.
I don't disagree with your history of DayTrader. However, I doubt that the EE version dies, at least not right away. There is, and will continue to be a need for samples on both programming models. Assuming that's true, I think it's potentially confusing to end up with two different applications called "DayTrader". So, I'm wondering if there should be some separation, naming-wise...
--kevan
Re: {DISCUSS] Home for Daytrader sample leveraging Aries
Posted by Joe Bohn <jo...@gmail.com>.
David Jencks wrote:
> Daytrader has a long history of insufficient maintenance and ad-hoc
> changes to suit the demands of the moment, followed by no cleanup of all
> the broken edges. IMO having an aries version of daytrader, the
> latest hot thing, will mean that the ee version will be completely
> dead. I don't think this is desirable. However, I'm not likely to work
> on any version of daytrader in the forseeable future.
I agree with the long history of insufficient maintenance and ad-hoc
changes with no cleanup of all the broken edges. I discovered that
first hand as I started looking into this. In fact, a good part of my
time has been in trying to remove or clean-up some of those broken edges.
In one respect starting afresh in Aries might help breath some new life
into this sample and force us to remove some of the cruft. In fact,
I've discovered that using the Aries programming model forces this to a
degree. The challenge, as you mention, will be to percolate that back
into the JavaEE version. I think that will be a challenge no matter
where the Aries version is located.
Joe
>
> thanks
> david jencks
>
> On Jan 12, 2010, at 11:17 AM, 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 <jo...@gmail.com> 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
>>>> (https://svn.apache.org/repos/asf/geronimo/sandbox/jbohn 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
>>>> any 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
>>>> I would
>>>> check in just the version with JDBC and the equinox assembly.
>>>> However, I
>>>> 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
>>>> and 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. I
>>>> 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
>>>> https://svn.apache.org/repos/asf/incubator/aries/trunk/samples
>>>>
>>>> Thanks,
>>>> Joe
>>>>
>>>>
>>
>>
>> --
>> Joe
>
>
--
Joe
Re: {DISCUSS] Home for Daytrader sample leveraging Aries
Posted by David Jencks <da...@yahoo.com>.
Daytrader has a long history of insufficient maintenance and ad-hoc
changes to suit the demands of the moment, followed by no cleanup of
all the broken edges. IMO having an aries version of daytrader, the
latest hot thing, will mean that the ee version will be completely
dead. I don't think this is desirable. However, I'm not likely to
work on any version of daytrader in the forseeable future.
thanks
david jencks
On Jan 12, 2010, at 11:17 AM, 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 <jo...@gmail.com> 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
>>> (https://svn.apache.org/repos/asf/geronimo/sandbox/jbohn 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 any 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 I would
>>> check in just the version with JDBC and the equinox assembly.
>>> However, I
>>> 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 and 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. I
>>> 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
>>> https://svn.apache.org/repos/asf/incubator/aries/trunk/samples
>>>
>>> Thanks,
>>> Joe
>>>
>>>
>
>
> --
> Joe
Re: {DISCUSS] Home for Daytrader sample leveraging Aries
Posted by zoe slattery <zo...@googlemail.com>.
Hi Alasdair
> I think you should add the samples into the top level pom to ensure
> they are built. We can worry about build time later.
>
I've just done it. they all build cleanly on my system and at least one
other person has checked the blog sample.
> Alasdair
>
> 2010/1/14 zoe slattery <zo...@googlemail.com>:
>
>> 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 <no...@apache.org>:
>>>
>>>
>>>> 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 <jo...@gmail.com> 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 <jo...@gmail.com> 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
>>>>>>> (https://svn.apache.org/repos/asf/geronimo/sandbox/jbohn 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
>>>>>>> any
>>>>>>> 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 I
>>>>>>> would
>>>>>>> check in just the version with JDBC and the equinox assembly. However,
>>>>>>> I
>>>>>>> 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
>>>>>>> and
>>>>>>> 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.
>>>>>>> I
>>>>>>> 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
>>>>>>> https://svn.apache.org/repos/asf/incubator/aries/trunk/samples
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Joe
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> --
>>>>> Joe
>>>>>
>>>>>
>>>
>>
>
>
>
>
Re: {DISCUSS] Home for Daytrader sample leveraging Aries
Posted by Joe Bohn <jo...@gmail.com>.
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!
Joe
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 <zo...@googlemail.com>:
>> 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 <no...@apache.org>:
>>>
>>>> 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 <jo...@gmail.com> 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 <jo...@gmail.com> 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
>>>>>>> (https://svn.apache.org/repos/asf/geronimo/sandbox/jbohn 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
>>>>>>> any
>>>>>>> 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 I
>>>>>>> would
>>>>>>> check in just the version with JDBC and the equinox assembly. However,
>>>>>>> I
>>>>>>> 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
>>>>>>> and
>>>>>>> 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.
>>>>>>> I
>>>>>>> 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
>>>>>>> https://svn.apache.org/repos/asf/incubator/aries/trunk/samples
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Joe
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> --
>>>>> Joe
>>>>>
>>>
>>
>
>
>
--
Joe
Re: {DISCUSS] Home for Daytrader sample leveraging Aries
Posted by Joe Bohn <jo...@gmail.com>.
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!
Joe
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 <zo...@googlemail.com>:
>> 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 <no...@apache.org>:
>>>
>>>> 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 <jo...@gmail.com> 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 <jo...@gmail.com> 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
>>>>>>> (https://svn.apache.org/repos/asf/geronimo/sandbox/jbohn 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
>>>>>>> any
>>>>>>> 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 I
>>>>>>> would
>>>>>>> check in just the version with JDBC and the equinox assembly. However,
>>>>>>> I
>>>>>>> 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
>>>>>>> and
>>>>>>> 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.
>>>>>>> I
>>>>>>> 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
>>>>>>> https://svn.apache.org/repos/asf/incubator/aries/trunk/samples
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Joe
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> --
>>>>> Joe
>>>>>
>>>
>>
>
>
>
--
Joe
Re: {DISCUSS] Home for Daytrader sample leveraging Aries
Posted by Alasdair Nottingham <no...@apache.org>.
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 <zo...@googlemail.com>:
> 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 <no...@apache.org>:
>>
>>>
>>> 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 <jo...@gmail.com> 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 <jo...@gmail.com> 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
>>>>>> (https://svn.apache.org/repos/asf/geronimo/sandbox/jbohn 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
>>>>>> any
>>>>>> 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 I
>>>>>> would
>>>>>> check in just the version with JDBC and the equinox assembly. However,
>>>>>> I
>>>>>> 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
>>>>>> and
>>>>>> 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.
>>>>>> I
>>>>>> 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
>>>>>> https://svn.apache.org/repos/asf/incubator/aries/trunk/samples
>>>>>>
>>>>>> Thanks,
>>>>>> Joe
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Joe
>>>>
>>
>>
>
>
--
Alasdair Nottingham
not@apache.org
Re: {DISCUSS] Home for Daytrader sample leveraging Aries
Posted by zoe slattery <zo...@googlemail.com>.
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 <no...@apache.org>:
>
>> 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 <jo...@gmail.com> 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 <jo...@gmail.com> 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
>>>>> (https://svn.apache.org/repos/asf/geronimo/sandbox/jbohn 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 any
>>>>> 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 I
>>>>> would
>>>>> check in just the version with JDBC and the equinox assembly. However, I
>>>>> 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 and
>>>>> 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. I
>>>>> 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
>>>>> https://svn.apache.org/repos/asf/incubator/aries/trunk/samples
>>>>>
>>>>> Thanks,
>>>>> Joe
>>>>>
>>>>>
>>>>>
>>> --
>>> Joe
>>>
>
>
Re: {DISCUSS] Home for Daytrader sample leveraging Aries
Posted by Jeremy Hughes <hu...@apache.org>.
+1 to putting it under samples at least for now!
Jeremy
2010/1/12 Alasdair Nottingham <no...@apache.org>:
> 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 <jo...@gmail.com> 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 <jo...@gmail.com> 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
>>>> (https://svn.apache.org/repos/asf/geronimo/sandbox/jbohn 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 any
>>>> 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 I
>>>> would
>>>> check in just the version with JDBC and the equinox assembly. However, I
>>>> 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 and
>>>> 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. I
>>>> 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
>>>> https://svn.apache.org/repos/asf/incubator/aries/trunk/samples
>>>>
>>>> Thanks,
>>>> Joe
>>>>
>>>>
>>
>>
>> --
>> Joe
>
Re: {DISCUSS] Home for Daytrader sample leveraging Aries
Posted by Alasdair Nottingham <no...@apache.org>.
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 <jo...@gmail.com> 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 <jo...@gmail.com> 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
>>> (https://svn.apache.org/repos/asf/geronimo/sandbox/jbohn 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 any 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 I would
>>> check in just the version with JDBC and the equinox assembly.
>>> However, I
>>> 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 and 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. I
>>> 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
>>> https://svn.apache.org/repos/asf/incubator/aries/trunk/samples
>>>
>>> Thanks,
>>> Joe
>>>
>>>
>
>
> --
> Joe
Re: {DISCUSS] Home for Daytrader sample leveraging Aries
Posted by Joe Bohn <jo...@gmail.com>.
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 <jo...@gmail.com> 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
>> (https://svn.apache.org/repos/asf/geronimo/sandbox/jbohn 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 any 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 I would
>> check in just the version with JDBC and the equinox assembly. However, I
>> 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 and 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. I
>> 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
>> https://svn.apache.org/repos/asf/incubator/aries/trunk/samples
>>
>> Thanks,
>> Joe
>>
>>
>
--
Joe
Re: {DISCUSS] Home for Daytrader sample leveraging Aries
Posted by Lin Sun <li...@gmail.com>.
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 <jo...@gmail.com> 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
> (https://svn.apache.org/repos/asf/geronimo/sandbox/jbohn 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 any 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 I would
> check in just the version with JDBC and the equinox assembly. However, I
> 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 and 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. I
> 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
> https://svn.apache.org/repos/asf/incubator/aries/trunk/samples
>
> Thanks,
> Joe
>
>
Re: {DISCUSS] Home for Daytrader sample leveraging Aries
Posted by Alasdair Nottingham <no...@apache.org>.
+1
2010/1/12 Joe Bohn <jo...@gmail.com>:
> Jeremy,
>
> That is a good point and one of my concerns as well. There will be fixes
> that will apply to both code streams and some that apply to just one or the
> other. Even with everything in one Apache project it would be a
> maintenance issue - but admittedly one that might be a little more difficult
> to forget about.
>
> Unfortunately I don't have a good solution for that concern yet apart from
> trying to be diligent. It may be that as both Aries and Geronimo continue
> to evolve it might make sense to merge both versions back into a common
> repository. However, at this point in time and for the near future, it
> seems best to me that this branch of the code reside in Aries while the pure
> JavaEE branch resides in Geronimo.
>
> Joe
>
> Jeremy Hughes wrote:
>>
>> Hi Joe, this sounds good and I think Aries is a good place for this.
>> You mention that the code has diverged from the JEE version. Do you
>> expect DayTrader/Aries to start life on its own or for there to be
>> some way of trying to keep the two projects in sync w.r.t bugs fixed,
>> function added? Perhaps that's just a discussion to have once
>> DayTrader/Aries can be run on Geronimo.
>>
>> Thanks,
>> Jeremy
>>
>> 2010/1/11 Joe Bohn <jo...@gmail.com>:
>>>
>>> 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
>>> (https://svn.apache.org/repos/asf/geronimo/sandbox/jbohn 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 any
>>> 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 I
>>> would
>>> check in just the version with JDBC and the equinox assembly. However, I
>>> 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 and
>>> 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. I
>>> 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
>>> https://svn.apache.org/repos/asf/incubator/aries/trunk/samples
>>>
>>> Thanks,
>>> Joe
>>>
>>>
>>
>
>
> --
> Joe
>
--
Alasdair Nottingham
not@apache.org
Re: {DISCUSS] Home for Daytrader sample leveraging Aries
Posted by Joe Bohn <jo...@gmail.com>.
Jeremy,
That is a good point and one of my concerns as well. There will be
fixes that will apply to both code streams and some that apply to just
one or the other. Even with everything in one Apache project it would
be a maintenance issue - but admittedly one that might be a little more
difficult to forget about.
Unfortunately I don't have a good solution for that concern yet apart
from trying to be diligent. It may be that as both Aries and Geronimo
continue to evolve it might make sense to merge both versions back into
a common repository. However, at this point in time and for the near
future, it seems best to me that this branch of the code reside in Aries
while the pure JavaEE branch resides in Geronimo.
Joe
Jeremy Hughes wrote:
> Hi Joe, this sounds good and I think Aries is a good place for this.
> You mention that the code has diverged from the JEE version. Do you
> expect DayTrader/Aries to start life on its own or for there to be
> some way of trying to keep the two projects in sync w.r.t bugs fixed,
> function added? Perhaps that's just a discussion to have once
> DayTrader/Aries can be run on Geronimo.
>
> Thanks,
> Jeremy
>
> 2010/1/11 Joe Bohn <jo...@gmail.com>:
>> 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
>> (https://svn.apache.org/repos/asf/geronimo/sandbox/jbohn 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 any 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 I would
>> check in just the version with JDBC and the equinox assembly. However, I
>> 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 and 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. I
>> 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
>> https://svn.apache.org/repos/asf/incubator/aries/trunk/samples
>>
>> Thanks,
>> Joe
>>
>>
>
--
Joe
Re: {DISCUSS] Home for Daytrader sample leveraging Aries
Posted by Jeremy Hughes <hu...@apache.org>.
Hi Joe, this sounds good and I think Aries is a good place for this.
You mention that the code has diverged from the JEE version. Do you
expect DayTrader/Aries to start life on its own or for there to be
some way of trying to keep the two projects in sync w.r.t bugs fixed,
function added? Perhaps that's just a discussion to have once
DayTrader/Aries can be run on Geronimo.
Thanks,
Jeremy
2010/1/11 Joe Bohn <jo...@gmail.com>:
>
> 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
> (https://svn.apache.org/repos/asf/geronimo/sandbox/jbohn 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 any 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 I would
> check in just the version with JDBC and the equinox assembly. However, I
> 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 and 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. I
> 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
> https://svn.apache.org/repos/asf/incubator/aries/trunk/samples
>
> Thanks,
> Joe
>
>
RE: {DISCUSS] Home for Daytrader sample leveraging Aries
Posted by Timothy Ward <ti...@hotmail.com>.
Hi Joe,
I think it is a great idea to have a sample that can be extended to use new Aries features as and when they appear. The range of features in Daytrader would be a great asset.
+1
Tim
> Date: Tue, 12 Jan 2010 09:49:31 +0000
> Subject: Re: {DISCUSS] Home for Daytrader sample leveraging Aries
> From: gcharters@googlemail.com
> To: aries-dev@incubator.apache.org
>
> Hi Joe,
>
> From your description it sounds like it makes a lot of sense to add
> daytrader to the aries/trunk/samples. I think getting the code
> checked in and then evolving it from there as Aries evolves is the
> right approach.
>
> +1 from me for adding this to the Aries samples.
>
> Regards, Graham.
>
> 2010/1/11 Joe Bohn <jo...@gmail.com>:
> >
> > 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
> > (https://svn.apache.org/repos/asf/geronimo/sandbox/jbohn 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 any 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 I would
> > check in just the version with JDBC and the equinox assembly. However, I
> > 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 and 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. I
> > 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
> > https://svn.apache.org/repos/asf/incubator/aries/trunk/samples
> >
> > Thanks,
> > Joe
> >
> >
_________________________________________________________________
We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now
http://clk.atdmt.com/UKM/go/195013117/direct/01/
Re: {DISCUSS] Home for Daytrader sample leveraging Aries
Posted by Graham Charters <gc...@googlemail.com>.
Hi Joe,
>From your description it sounds like it makes a lot of sense to add
daytrader to the aries/trunk/samples. I think getting the code
checked in and then evolving it from there as Aries evolves is the
right approach.
+1 from me for adding this to the Aries samples.
Regards, Graham.
2010/1/11 Joe Bohn <jo...@gmail.com>:
>
> 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
> (https://svn.apache.org/repos/asf/geronimo/sandbox/jbohn 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 any 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 I would
> check in just the version with JDBC and the equinox assembly. However, I
> 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 and 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. I
> 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
> https://svn.apache.org/repos/asf/incubator/aries/trunk/samples
>
> Thanks,
> Joe
>
>
Re: {DISCUSS] Home for Daytrader sample leveraging Aries
Posted by Jeremy Hughes <hu...@apache.org>.
Hi Joe, this sounds good and I think Aries is a good place for this.
You mention that the code has diverged from the JEE version. Do you
expect DayTrader/Aries to start life on its own or for there to be
some way of trying to keep the two projects in sync w.r.t bugs fixed,
function added? Perhaps that's just a discussion to have once
DayTrader/Aries can be run on Geronimo.
Thanks,
Jeremy
2010/1/11 Joe Bohn <jo...@gmail.com>:
>
> 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
> (https://svn.apache.org/repos/asf/geronimo/sandbox/jbohn 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 any 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 I would
> check in just the version with JDBC and the equinox assembly. However, I
> 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 and 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. I
> 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
> https://svn.apache.org/repos/asf/incubator/aries/trunk/samples
>
> Thanks,
> Joe
>
>