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?).
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) 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). 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 > > --------------------------------------------------------------------- > 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]
