On Sun, Aug 31, 2008 at 2:59 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin (JIRA) ha scritto: >> >> * Entry point: >> * SieveFactory > > This should only be used to wire together the default implementations, > otherwise direct objects wiring should be allowed for > extensibility/integration.
i see no reason why SieveFactory needs to be coupled to the default implementations. the factory should be either abstract or an interface and loaded by the configuration. > E.g: I expect the sievefactory to inject a standard logger while components > should le me inject my own logging service. > http://svn.apache.org/repos/asf/james/jspf/trunk/resolver/src/main/java/org/apache/james/jspf/impl/DefaultSPF.java > >> * Configuration: >> * ConfigurationManager >> * ComparatorManager >> * TestManager >> * CommandManager > > IMHO the 4 above could even be merged to a single factory that simply > produce the configuration of the available objects and let creating new > instances for them. ConfigurationManager loads the maps from property files for the remaining 3. probably a single interface would suffice. > This is similar to TermsFactory/DefaultTermsFactory we have in jspf: > http://svn.apache.org/repos/asf/james/jspf/trunk/resolver/src/main/java/org/apache/james/jspf/impl/DefaultTermsFactory.java > >> * Logger > > My preference for libraries logging is to have a custom Logger interface > injected into components and then provide some implementation (ConsoleLogger > / commons-logging-logger). > http://svn.apache.org/repos/asf/james/jspf/trunk/resolver/src/main/java/org/apache/james/jspf/core/Logger.java > http://svn.apache.org/repos/asf/james/jspf/trunk/resolver/src/main/java/org/apache/james/jspf/impl/Log4JLogger.java i'm not sure it's worthwhile to create yet another logger bridge in this case. injecting a JCL log is probably good enough. >> * Magic context: >> * ConditionManager >> * CommandStateManager > > As I wrote in the specific mail I would probably move both of them to a > simple Session object that could be added to Executable(Command|Test). context is a more common name for this pattern > About thread safety I think the goal should be to have the whole script > execution reentrant so that a single instance of a parsed script can be used > by multiple threads. +1 > Parsing instead can be thought to happen in a single thread. it's an atomic function: parsing produces a executor - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
