geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lin Sun" <linsun....@gmail.com>
Subject Re: Remove samples myphonebook and mytime?
Date Fri, 18 Jul 2008 19:51:50 GMT
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 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.

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?

Lin



On Thu, Jun 12, 2008 at 1:41 PM, David Jencks <david_jencks@yahoo.com> 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 <david_jencks@yahoo.com>
>> 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
>> http://www.JacekLaskowski.pl
>
>

Mime
View raw message