geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lin Sun" <>
Subject Re: Remove samples myphonebook and mytime?
Date Mon, 21 Jul 2008 17:11:40 GMT

I agree that users won't be annoyed by too many samples as long as
they are validated/updated.  So I agree if you already validated these
two samples, we can go ahead and release them for 2.1.2.

On Fri, Jul 18, 2008 at 5:12 PM, Joe Bohn <> wrote:

> I don't think users have ever been annoyed because we provided too many
> samples.  However, I agree that if we keep them we must ensure that they are
> functional and documented.  Is there some issue with functionality/doc of
> the mytime or myphonebook samples?  If they are updated and functional
> (which I have validated that they are) then I think we should go ahead and
> release them.  If they do fall behind on a future release we can decide at
> that time if it is a better use of our time to remove them rather than
> update them.  However, for 2.1.2 I think the maintenance issue is a moot
> argument.

I don't have a strong opinion as to removing the 3 entities or 1
entities, and I don't know the histories of these samples either.   If
the samples are serving the exact functionality purpose, by removing
the duplicate one, we can save our time and energy to work on a new
sample that demonstrates a different functionality or something else.


> Ok, so if there isn't any difference between the 3 entities and 1 entity ...
> and we really want to eliminate duplication ...  then let's remove the
> sample with 3 entities (bank).  The original proposal here was to remove the
> sample with 1 entity (myphonebook).  The sample with 1 entity was added as a
> "very simple" sample and, IIRC it was added after we had the 3 entity
> sample.  So, it would seem there was already a case where a user was
> confused by 3 entities vs. 1 and hence the 1 entity sample was created.
>  Also, it will be easier to maintain and update the sample with 1 entity in
> the future rather than 3 if your primary argument is the work involved in
> maintenance.
> One other thought on bank ... I wonder if it was envisioned as growing into
> a more complex sample and it just never "grew-up".  If we somehow decide to
> keep bank but remove myphonebook then I hope we can put something in place
> to prevent a simple sample from growing too complex. The thing I like about
> myphonebook and mytime is that they were created with the idea of being very
> simple and nothing else.

> Here again, if we don't want to keep both, then let's remove the sample that
> is less common and/or more complex.  I'm not sure which that is but the
> mytime sample was added long after calculator and the motivation for adding
> it was the need for a "very simple" example.  Perhaps calculator has been
> simplified over time or perhaps it never grew-up either.  But it seems that
> it didn't meet the need when mytime was first introduced.  I wonder what has
> changed since then?
>> Lin
>> On Thu, Jun 12, 2008 at 1:41 PM, David Jencks <>
>> wrote:
>>> I think you , joe, donald, and hernan are being completely unrealistic
>>> about
>>> the likelihood of these samples being maintained even if they get updated
>>> and the value they add and the potential for total confusion for users
>>> when
>>> they see a bunch of samples doing exactly the same thing.
>>> Before suggesting removing them I considered the overlap.  Let me restate
>>> the extent of overlap:
>>> bank has 3 entities, myphonebook has one.  To me this is 100% overlap
>>> mytime and calculator-stateless both demonstrate a stateless ejb with no
>>> connection to the outside world.  Again to me this is 100% overlap.
>>> Rather than spending our non-existent energy maintaining a bunch of badly
>>> written samples that do exactly the same thing I'd rather see some
>>> faintly
>>> more realistic samples with a broader range such as an ejb that sends jms
>>> messages and a jsf sample.  There's also a lot of room for improvements
>>> in
>>> the samples I think we should keep such as:
>>> - having the web client in a different war than the jaxws service in the
>>> jaxws example
>>> - having an ejb that sends messages in the jms example, probably in a
>>> different ejb jar.
>>> - actually saving the new users in the timereport jar.  I'd recommend
>>> using
>>> jpa here.  This would be an example of using jpa from the web tier,
>>> currently missing IIUC.
>>> - demonstrating switching datasources
>>> Although bank and customer-service are pretty similar, I haven't
>>> recommended
>>> removing one because I modified customer-service to demonstrate container
>>> managed persistence contexts and left bank demonstrating application
>>> managed
>>> persistence contexts.
>>> I am not going to work on these two samples so if you really want to keep
>>> them please divvy up the work and update them and their documentation.
>>>  My
>>> understanding is that Joe would like to get the samples released fairly
>>> soon.
>>> thanks
>>> david jencks
>>> On Jun 11, 2008, at 11:52 PM, Jacek Laskowski wrote:
>>>> On Thu, Jun 12, 2008 at 2:18 AM, David Jencks <>
>>>> wrote:
>>>>> I'd like to remove the myphonebook and mytime samples.  AFAICT they
>>>>> duplicate functionality demonstrated in bank.
>>>>> mytime has a web app accessing a stateless ejb
>>>>> myphonebook has a web app accessing a stateless ejb that uses a single
>>>>> jpa
>>>>> entity (with an application managed persistence context)
>>>>> bank has a web app accessing a stateless ejb that uses 3 jpa entities
>>>>> (although they aren't implemented well) using application managed
>>>>> persistence context
>>>>> customer-service has a web app accessing a stateless ejb that uses one
>>>>> jpa
>>>>> entity using a container managed persistence context.
>>>>> Any objections?
>>>> Yup! Let's keep them till they're fixed and once they are we could
>>>> notice their value (I know it sounds weird, but they're pretty small
>>>> to digest for novices and that's their major value). Let me take a
>>>> look at them, okey?
>>>> Jacek
>>>> --
>>>> Jacek Laskowski

View raw message