Robert Burrell Donkin ha scritto:
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.
My think is that if it is an entry point it cannot be abstract or an
interface. The entry point is the object I instantiate to use sieve (in
my terms).
But I guess here we are simply using different terms. It's better I wait
and look at how you will change code and maybe I should better speak
with code in reply :-)
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.
My issue with JCL injecting is that Logger does not have a
getChildLogger. So if you inject a JCL logger you can't have different
names in the various components.
Furthermore there are many people not happy with commons-logging, and
they often don't understand the difference between injected
commons-logging and static commons-logging usage. The bad name for
loggers born by their static usage.
BTW jsieve already depends on commons-logging so moving to DI for it
would be already a good step.
* 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
I agree. Expecially if it is no more needed at parsing level for the
coordinates.
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
I meant it can be synchronized. IMHO making this atomic function thread
safe does not worth it. If someone have to really parse multiple scripts
with multiple threads they can use multiple parser instances.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
