Hi Stefano, comments inside...
2010/12/17 Stefano Bagnara <[email protected]>: > I find useful to have automatic search of mailets and the current way > is not so bad (as we only do this once at the start). But we don't use > the same method for other components (like the protocol handlers) and > maybe the current method is not OSGi friendly (is this a motivation > for your proposal?). Thats the point. We use the "full name" everywhere else so I just try to make it consistent. And you are right the current implementation is not really "OSGI friendly". And like I said name clashes could hit devs easily with the current implementation.. > > That said I'm fine with a simplification here, but maybe we should at > least keep a default package so that basic mailets don't need the full > package and most configurations are easier to read. > > org.apache.james.transport.mailets (for mailets) > org.apache.james.transport.matchers (for matchers) Like stated above I would be more in favor to have it consistent all the way around. But I think we could do what you propose too.. Like check if the "name" contains a "." and if not just append the "default" package before try to load it.. > > Talking about future the good way would be mailets autoregistering to > the container so that the container already knows what mailets are > available without the class instantiation attempts. And maybe it would > also help users/developers to see what mailets are available in the > environment (not sure what's the best way to do this, just loud > thinking). Exactly what I had in mind.. See the commit log: Log: Get rid of InstanceFactory when loading UsersRepository, VirtualUserTable and DomainList. This is done a BeanFactoryPostProcessor which parse the configuration file for each of these and register a bean for it in the spring context. Something similar should be done when loading Mailets/Matchers and CommandHandler/LineHandler/ConnectHandler/Hook implementations > > Stefano > > 2010/12/17 Norman Maurer <[email protected]>: >> Hi there, >> >> I know many proposal this week but its time to "break" stuff now ;) >> >> I would like to propose that we remove the "mailetpackages" and >> "matcherpackages" configuration option from the mailetcontainer.xml >> file. This would force the users to use the full classname ( with >> package) on every matcher/mailet configuration. >> >> So something like this: >> >> <mailet match="org.apache.james.transport.matchers.All" >> class="org.apache.james.transport.mailets.ToProcessor"> >> >> >> I think how we do it at the moment just is an ugly hack and give use >> not really anything back (except that we don't need to write the >> packagename everytime). Its also error-phrone as its possible that two >> packages contain the same classname. As mailets and matchers are >> pluggable by the users/dev this could happen really easy. Also the >> implementation is just a hack (IMHO). >> >> Just a snipped: >> >> for (final String packageName:packages) { >> final String className = packageName + mailetName; >> try { >> final Mailet mailet = >> (Mailet)factory.newInstance(Thread.currentThread().getContextClassLoader().loadClass(className)); >> >> final MailetConfigImpl configImpl = new >> MailetConfigImpl(); >> configImpl.setMailetName(mailetName); >> configImpl.setConfiguration(configuration); >> configImpl.setMailetContext(mailetContext); >> mailet.init(configImpl); >> >> return mailet; >> } catch (ClassNotFoundException cnfe) { >> //do this so we loop through all the packages >> } >> } >> >> I know the change is somewhat heavy but I think if we want todo it now >> is the time before a final 3.0 will get cut. >> >> Wdyt ? >> Norman Bye, Norman --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
