On one hand, given that the transports have been split into several modules, it makes sense to not activate the less common ones by default, because it would result in an error when they are not on the classpath. But I also see your point, Asankha, that if these transports are on the classpath, it is annoying that people are forced to write their own axis2.xml in order to use them. Maybe the best solution would be to allow to mark transports in axis2.xml as "optional" and enhance Axis2 so that if the implementation class of a transport marked this way can't be loaded, it just ignores it.
Andreas On Mon, Nov 3, 2008 at 16:37, Asankha Perera <[EMAIL PROTECTED]> wrote: > Sumedha >> >> Until recently we used to have commented out blocks of JMS & SMTP sample >> configurations within axis2.xml. But I do not see these now. >> Were these removed on purpose? Or did these get deleted accidentally >> during recent transport module relocation? If so shall I add them back? >> I want to add a sample configuration for XMPP transport & wondering where >> to put it. > > Yes, also I noticed that someone had commented the JMSSender from the > default axis2.xml, which makes a default client unable to use the JMS sender > which is quite troublesome for users IMHO. Its not the first time this > happened as I remember :-( .. we should have all possible transports enabled > on the default axis2.xml files, and also include example configuration > options where applicable > > asankha > > -- > Asankha C. Perera > http://adroitlogic.org > > http://esbmagic.blogspot.com > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
