On 8 Jul 2009, at 13:51, Vladimir Blagojevic wrote:
Guys,
Currently as soon as transactional element is in xml config file,
even if transactionManagerLookupClass is not specified, it defaults
to a certain value. Having these minor semantic rules require
special processing of elements during xml reading. Of course, the
design accommodates these special rules (case of
CacheLoaderManagerConfig where we add individual
CacheLoaderConfigs). So far there are only two special processing
elements (another is clustering).
Can we avoid it for transaction element, and if yes, how? By
requiring transactionManagerLookupClass to be mandatory?
As far as possible I would prefer that we have sensible defaults, from
a user experience point of view. We have a TransactionManagerLookup
impl that deals with *most popular* TMs registered in JNDI and this
is, IMO, a sensible default.
As you said, this is the same for the <transport /> element, which
defaults to a JGroupsTransport. We don't have anything else here at
the moment, but people have asked for this to be an extension point.
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org