geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: Remove samples myphonebook and mytime?
Date Fri, 18 Jul 2008 21:12:37 GMT
Lin Sun wrote:
> I agree with David - if two samples are completely duplicate we need
> to remove one, given the time we need to spend to maintain them in svn
> and wiki and the fact that  the duplicate sample doesn't provide any
> extra usage.
> We should divide samples by its functionalities.   At the end, the
> samples are used to demonstrate a particular function, and I don't
> think 3 entities or 1 entities will make a difference in helping users
> consume them.  It will be annoying to the user if we release two
> samples with duplicate functions but we fail to update one of them due
> to lack of time/resource.

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 looked at bank and myphonebook closely (both are stateless ejb, and
> application managed persistence context with JPA) thus I think we
> should remove one of them.

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.

> mytime and calculator (yes, we changed the name from
> calculator-stateless-pojo to calculator) are mostly the same too (both
> are stateless ejb).   The only difference is that mytime web client
> uses JNDI to look up the bean while calculator client uses @EJB
> annotation to inject the session bean's interface.   I don't know if
> it is worthy to keep them because of the difference here?

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