Hi, There's a bit of a mess now with regards to XmlConfigurationParser implementations. There're now 3 of them: AutomatedXmlConfigurationParserImpl InfinispanConfiguration XmlConfigurationParserImpl Which one should we be using to parse XML configuration files from unit tests? The reason I'm asking is because parsing via InfinispanConfiguration returns different results to parsing via previous XmlConfigurationParserImpl. For example: If XmlConfigurationParserImpl found a transport element but transport class, it gave JGroupsTransport as default, hence a cluster channel would be created. However, parsing via InfinispanConfiguration, if no transportClass has been defined, no cluster channel is created. We need to keep one and deprecate the others making sure we note things like this, i.e. if no transport class is defined, by default we use JGroupsTransport (something which IMO makes a lot of sense) Cheers, -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

InfinispanConfiguration is JAXB based parser. I will remove the other two and all related classes. The details you noticed Galder are intricacies of JAXB parsing. We should always specify class from now on. I will still look if it is possible to resolve this and have 100% compatibility with previous parser - but believe me it is not always possible.

On 8/4/09 1:59 PM, Manik Surtani wrote: > > A question for Vladimir, I believe. > > On 4 Aug 2009, at 11:10, Galder Zamarreno wrote: > > >> Hi, >> >> There's a bit of a mess now with regards to XmlConfigurationParser >> implementations. There're now 3 of them: >> >> AutomatedXmlConfigurationParserImpl >> InfinispanConfiguration >> XmlConfigurationParserImpl >> >> Which one should we be using to parse XML configuration files from >> unit >> tests? >> >> The reason I'm asking is because parsing via InfinispanConfiguration >> returns different results to parsing via previous >> XmlConfigurationParserImpl. >> >> For example: If XmlConfigurationParserImpl found a transport element >> but >> transport class, it gave JGroupsTransport as default, hence a >> cluster >> channel would be created. However, parsing via >> InfinispanConfiguration, >> if no transportClass has been defined, no cluster channel is >> created. >> >> We need to keep one and deprecate the others making sure we note >> things >> like this, i.e. if no transport class is defined, by default we use >> JGroupsTransport (something which IMO makes a lot of sense) >> >> Cheers, >> -- >> Galder Zamarreño >> Sr. Software Engineer >> Infinispan, JBoss Cache >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > > -- > Manik Surtani > manik(a)jboss.org > Lead, Infinispan > Lead, JBoss Cache > http://www.infinispan.org > http://www.jbosscache.org > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev >

On 8/11/09 1:22 PM, Manik Surtani wrote: > > On 11 Aug 2009, at 10:39, Vladimir Blagojevic wrote: > >> InfinispanConfiguration is JAXB based parser. I will remove the >> other two and all related classes. >> The details you noticed Galder are intricacies of JAXB parsing. We >> should always specify class from now on. I will still look if it >> is possible to resolve this and have 100% compatibility with >> previous parser - but believe me it is not always possible. > > Always specifying a class may be unnecessarily verbose. Sensible > defaults wherever possible, remember? > I do :) but this is different. In some cases we follow a rule that if we have xml element present in conf file we use certain defaults for attributes and if it is not present then use others. I was referring to that case. Apologies for confusion.

For example: If XmlConfigurationParserImpl found a transport element but transport class, it gave JGroupsTransport as default, hence a cluster channel would be created. However, parsing via InfinispanConfiguration, if no transportClass has been defined, no cluster channel is created.

On 8/11/09 1:39 PM, Manik Surtani wrote: > > Wasn't this about the default Transport impl, which is the > JGroupsTransport? :) From Galder's original email: > >> For example: If XmlConfigurationParserImpl found a transport >> element but >> transport class, it gave JGroupsTransport as default, hence a >> cluster >> channel would be created. However, parsing via >> InfinispanConfiguration, >> if no transportClass has been defined, no cluster channel is >> created. > > Basically if someone specifies <transport /> but does not specify > the transportClass attribute, it should still default to the > JGroupsTransport - since that is the sensible default. > Resolved and committed. Don't blame for for being slow. I just spent 10 days on a beach :)