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
