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 Tue, 24 Jun 2008 16:24:25 GMT
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.


Thanks for the detailed response and pointing out the overlap again. 
I'll take a closer look at the overlaps you have pointed out.  If it is 
truly 100% overlap (meaning both samples include the same level of 
detail) then I agree that we don't need multiple samples.  However, it 
is really a very simple sample and a more complex sample then I think 
there is value in keeping the simple example.  A user that just wants to 
understand the most fundamental concept without additional clutter could 
be confused by the more complex sample.  On the other hand, I think it's 
good to have the more complex examples too since they are a little 
closer to real world scenarios even if they are very contrived.  I was 
under the impression that this extremely simple vs. more complex 
scenarios were what we had in the samples that you pointed out.

> 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

All good enhancements.  My only concern is to ensure that we have some 
very basic samples for those just starting out.  If they truly are the 
most basic scenarios then it was my hope that there should be very 
little if any change from release to release and hence very low maintenance.

> 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.

That sounds like a good split to me.

> 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.

I hope to get back on this as soon as I catch up on email.

> 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