On 8/21/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > > Comments inline. > > Thanks, > Raymond > > ----- Original Message ----- > From: "ant elder" <[EMAIL PROTECTED]> > To: <tuscany-dev@ws.apache.org> > Sent: Tuesday, August 21, 2007 9:12 AM > Subject: Re: Patch for TUSCANY-1356 > > > > On 8/21/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > >> > >> Simon Nash wrote: > >> > > >> > ant elder wrote: > >> >> On 8/20/07, Simon Nash <[EMAIL PROTECTED]> wrote: > >> >> > >> >>> I'm restarting the discussion on this because the previous thread > [1] > >> >>> did not reach a conclusion. I thought it would be useful to > >> >>> summarize > >> >>> the issues with the extension samples as they stand, and explain > how > >> >>> the patch for TUSCANY-1356 resolves these issues. > >> >>> > >> >>> In the implementation-crud sample (the client application code), we > >> >>> have > >> >>> CRUDClient.java, crud.composite, and CRUDTestCase.java. > >> >>> CRUDClient.java > >> >>> and crud.composite together provide a sample client that exercises > >> >>> implementation-crud-extension, and these two files are correctly > part > >> >>> of implementation-crud because they are not part of the extension > >> >>> jar. > >> >>> The problem with implementation-crud is the inclusion of > >> >>> CRUDTestCase.java > >> >>> , > >> >>> which does not use or test any of the above client code, but is > just > >> >>> a > >> >>> copy of the same file from implementation-crud-extension (and > >> >>> executed > >> >>> by mvn when implementation-crud-extension is built). The patch for > >> >>> TUSCANY-1356 eliminates this duplicate copy of CRUDTestCase.java in > >> >>> implementation-crud and adds a new itest (not part of the samples) > >> that > >> >>> runs the implementation-crud client code to make sure it executes > OK. > >> >>> > >> >>> The crud.composite file from the implementation-crud sample client > >> >>> is also > >> >>> duplicated as part of the test code for > >> >>> implementation-crud-extension. > >> >>> There is no need for this code to be duplicated. The patch for > >> >>> TUSCANY-1356 eliminates this duplicate copy of crud.composite by > >> having > >> >>> the JUnit test for implementation-crud-extension use the > >> crud.composite > >> >>> file that is part of implementation-crud. > >> >>> > >> >>> Similarly, in the binding-echo-extension sample, under src/test > >> >>> there are > >> >>> duplicates of the implementation code, composite file, and JUnit > >> >>> test code > >> >>> from binding-echo. The patch for TUSCANY-1356 removes duplicate > code > >> >>> from binding-echo-extension by having the JUnit tests in > >> >>> binding-echo-extension take this code from binding-echo, adds a > >> >>> non-sample > >> >>> itest to exercise EchoBindingClient.java from binding-echo, and > >> removes > >> >>> redundant JUnit test code from binding-echo (not needed because the > >> >>> JUnit > >> >>> tests in binding-echo-extension contains exactly the same code). > >> >>> > >> >>> With these changes, all duplicate code is eliminated from these > >> >>> samples, > >> >>> all sample code is tested either by sample JUnit tests or separate > >> >>> itests, and the distinction between the extension and > >> >>> client/application > >> >>> samples is much clearer. > >> >>> > >> >>> Simon > >> >>> > >> >>> [1] > >> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19026.html > >> >> > >> >> > >> >> > >> >> How about instead just deleting the implementation.crud sample? > We've > >> >> the > >> >> implementation.pojo sample now which seems like a better sample to > me > >> >> anyway. > >> >> > >> > The patch for TUSCANY-1356 also corrects similar problems with the > >> > binding-echo and binding-echo-extension samples. This part of the > >> > patch > >> > could be applied while we consider whether or not to delete > >> > implementation-crud. > >> > > >> > I looked at the implementation-pojo-extension sample. It has no > >> > associated > >> > client to run "out of the box" using ant. The issues addressed by > >> > TUSCANY-1356 arose out of the work that was done on > >> > implementation-crud and > >> > binding-echo to factor them into an extension sample and > >> > client/application > >> > sample so that the client code could run out of the box using > ant. If > >> we > >> > decide to replace implementation-crud by implementation-pojo, we > would > >> > need > >> > to fix up implementation-pojo-extension to add a client sample, with > >> code > >> > divided between the extension sample and the client sample in the > same > >> > way > >> > that the patch for TUSCANY-1356 does. > >> > > >> > Simon > >> > > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > > >> > >> I would like to keep implementation-crud as it's showing an > >> implementation type different from a POJO. Implementation-crud and > >> implementation-pojo are meant to show different approaches to component > >> implementations, and I'll be concerned if our only implementation > sample > >> leads all people down the POJO path. If people have serious and > concrete > >> enough issues with implementation-crud, please raise them and we should > >> take a look at them. > > > > +1 to keep the implementation-crud. Indeed, I think it should be the > primary > example to demonstrate how to add a new implementation type to Tuscany. > I'm > not very sure if we have to force the extension developers to only take > the > pattern that the extension-helper supports (for example, I might prefer to > load the extension metadata in the SCDL using SDO or JAXB). Meanwhile, I > think the extension-help needs to be further polished.
Absolutely, no one is saying not to show the various extension SPI's just that, IMHO, implementation.pojo would be a much better example than implementation.crud > > > One of the things I've found confusing with implementation.crud is that > > because it has a single fixed service interface you can easily just have > > the > > component use implementation.java to invoke a CRUD impl and use > properties > > for whatever configuring it needs, so it makes you wonder why using an > > extension is even necessary. > > > > There is a big difference. To add an implementation type for CRUD, the > CRUD > function is provided by the extension logic and reused by application > developers. If we use implementation.java, then the CRUD is in the > business > logic code. > > BTW, a fixed interferce is also interesting. RESTful services are good > examples. Sure - for bindings - I'm still not convinced this is a great example for an implementation though. ...ant
