-Donald 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 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
smime.p7s
Description: S/MIME Cryptographic Signature
