Re: svn commit: r660588 [1/3] - in /geronimo/samples/trunk: ./ samples/ samples/CustomerService/CustomerService-ear/ samples/CustomerService/CustomerService-ear/src/main/resources/ samples/CustomerService/CustomerService-ear/src/main/resources/META-INF/ sa...

[Kevan Miller <ke...@gmail.com>]

On May 27, 2008, at 5:12 PM, David Jencks wrote:

>
> On May 27, 2008, at 1:31 PM, Joe Bohn wrote:
>
>>
>> David,
>>
>> Thanks for committing this to trunk.  It will be great to have the  
>> itests for samples.
>>
>> I have few questions on the shared sample datasource plugin (not  
>> just for David to answer):
>>
>> 1) Big Picture Question:  Is this what the users are typically  
>> expecting when they work through a sample regarding any necessary  
>> datasource entries?  Until now the samples included the datasource  
>> definitions within the application (ear).  They could follow the  
>> sample without using the plugins at all.  Now it would appear that  
>> they must install the SampleDatasource plugin before they can  
>> install any sample and they will not see the datasource definition  
>> within the sample itself.  David and I have already discussed this  
>> on IRC some but I was wondering what others thought.
>
> My point of view here is that we should be trying to demonstrate  
> best practices for real projects whenever possible.  IMNSHO best  
> practice is currently to deploy datasources, jms stuff, etc as  
> separate plugins so its easy to switch.  For instance, switching  
> between derby and db2, and switching between test and production  
> setups.  The samples pretty much require you to be using maven  
> anyway, so I think that demonstrating and encouraging use of the  
> plugin infrastructure in the "best" way is a good idea.

I guess I agree. However, I'd also like to be sure we have good  
documentation on how to define datasource definitions in their  
applications, and make sure we identify this alternative in our  
samples documentation.

>
>
> Note that the datasource plugin is built as one of the sample  
> modules, so its entirely visible, just not in the individual sample  
> project.
>
> We could also demonstrate packaging the datsource/jms in with the  
> sample app as alternative plugins.  To do this I'd recommend using  
> the external-module feature so we don't have to actually package the  
> tranql code into each ear.  Then the apps could be completely  
> datasource free and we'd have 2 plugins (actually 4, 2 ds types X 2  
> web servers).

I agree.

>>
>> 2) It seems that the datasource is still being defined within the  
>> ear (at least partially).  The geronimo-application.xml for each  
>> sample still includes a module for the tranql-connector-ra-1.3.rar  
>> and a reference to the application specific pool definition in the  
>> alt-dd. See for example, /bank-ear/src/main/resources/META-INF/ 
>> geronimo-application.xml.  I'm not well versed on this but I  
>> thought this meant that the application was still defining a pool  
>> based upon BankPool.xml.
>
> These plans aren't used in the plugin construction.  If we switched  
> them to use the external-module feature then the ear could also be  
> deployed directly to the server, not as a plugin, using these plans.
>
> I think it would be a good idea to make sure the plugin plans are  
> complete and don't rely on any partial plans in the ears.  I didn't  
> work on this step.
>>
>>
>> 3) The pool definitions are slightly different for the various  
>> samples.  I think most of this was just due to different names for  
>> the pools. However, there are some other differences.  Some include  
>> a username and others do not.  Also, the TimeReportPool.xml  
>> includes a gbean definition for the TimeReportRealm.  How are these  
>> differences addressed in these changes and are the samples still  
>> functional?
>
> As noted above, the geronimo-application.xml plans in the ears arent  
> used for the plugins.  I made all the samples deploy as plugins into  
> framework server.  To do this yourself run
>
> mvn clean install -Pit
>
> I didn't write any actual tests of the plugins beyond this "fail if  
> they don't deploy" "test".  More tests would be great but perhaps  
> beyond what we can really do for 2.1
>
> We should certainly uniformize the internal plan datasource  
> definitions if we don't remove them.

I'd certainly expect that we'd have at least stepped through the  
actual sample apps. Any volunteers?

--kevan