You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org> on 2008/08/31 12:25:44 UTC
[jira] Commented: (JSIEVE-16) Singletons -> IoC
[ https://issues.apache.org/jira/browse/JSIEVE-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627296#action_12627296 ]
Robert Burrell Donkin commented on JSIEVE-16:
---------------------------------------------
The [pseudo-]singletons can be categorised into:
* Entry point:
* SieveFactory
* Configuration:
* ConfigurationManager
* ComparatorManager
* TestManager
* CommandManager
* Logger
* Magic context:
* ConditionManager
* CommandStateManager
Should be possible to factor magic context into a Context which is passed though on execution
Should be possible to separate concerns about configuration from execution by creating interfaces and a default builder
> Singletons -> IoC
> -----------------
>
> Key: JSIEVE-16
> URL: https://issues.apache.org/jira/browse/JSIEVE-16
> Project: jSieve
> Issue Type: Task
> Reporter: Robert Burrell Donkin
> Fix For: 1.0
>
>
> The current code uses per-thread pseudo-singletons. This requires complex and fragile sychronisation code.
> Factor out interfaces and inject dependencies. Any synchronisation required should be provided by the user of library.
> See http://mail-archives.apache.org/mod_mbox/james-server-dev/200708.mbox/%3cf470f68e0708061234p13943d3fm3497b6fdfff4d203@mail.gmail.com%3e thread for more details.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: getChildLogger (Was: [jira] Commented: (JSIEVE-16) Singletons
-> IoC)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Tue, Sep 2, 2008 at 8:55 AM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On Mon, Sep 1, 2008 at 2:30 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>>> Robert Burrell Donkin ha scritto:
>>>>> On Sun, Aug 31, 2008 at 6:13 PM, Stefano Bagnara <ap...@bago.org>
>>>>> wrote:
>>>>>> Robert Burrell Donkin ha scritto:
>>> <snip>
>>>
>>>>>>> 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.
>>>>> yes - that's probably the biggest mistake we made when creating the
>>>>> API. then again, the JEE specifications weren't broken at that time so
>>>>> it didn't seem necessary to cater for injecting loggers.
>>>> OT: why not to starting a commons-logging 2.0 that has this feature?
>>> 1. ceki already did
>> Do you speak about ILoggerFactory in slf4j or something else?
>
> slf4j
I've read something, and I think it is a pity that is has been
implemented as a separated interface.
A ChildGeneratingLogger spi like the LocationAwareLogger would have been
much better, IMHO.
http://www.slf4j.org/api/org/slf4j/spi/LocationAwareLogger.html
But I admit I may miss something and Ceki arguments are often very
convincing!
>>> 2. JCL's good enough so nothing else is ever to reach critical mass
>> Joerg Hohwiller crusade to add a new extended interface for the Ioc friendly
>> logger (e.g: IoCLogger) was not so bad.
>> This could have been easy even in a minor release and it could have been
>> added to api only at first.
>
> there wasn't any realistic way to add it without breaking
> compatibility. we analysed many permutations but in the JCL2.0 was
> never going to fly,
>
>>> 3. really the JCP should just get ceki to create a decent logging API
>> true, but I don't expect a "java.util.newlogging" ever..
>
> all it requires is energy
>
>>> 4. i've wasted too many hundreds of hours on logging already
>> I understood this while looking markmail for this getChildLogger issue!
>> Thank you!
>>
>> Interesting! It's cool to know that someone else see things like me :-)
>>
>> http://markmail.org/message/4hlquicqcyovfv6a
>> http://markmail.org/message/ynsu2uutkh2z7mfp
>>
>> Expecially http://markmail.org/message/3lnqomomugq3xyec
>>
>> I see at the end of 2005 there was a patch to add getChildLogger and a
>> discussion about releasing and then add it, but I didn't found what happened
>> then. I guess it simply died or you found blocking issues... it's a pity.
>
> it would have required a major version increment. the collections hell
> was bad but JCL would have been much, much worse. better to leave the
> field clear for ceki.
Thank you again for the explanation/revival.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: getChildLogger (Was: [jira] Commented: (JSIEVE-16) Singletons -> IoC)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Tue, Sep 2, 2008 at 8:55 AM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Mon, Sep 1, 2008 at 2:30 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>>
>>> Robert Burrell Donkin ha scritto:
>>>>
>>>> On Sun, Aug 31, 2008 at 6:13 PM, Stefano Bagnara <ap...@bago.org>
>>>> wrote:
>>>>>
>>>>> Robert Burrell Donkin ha scritto:
>>
>> <snip>
>>
>>>>>> 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.
>>>>
>>>> yes - that's probably the biggest mistake we made when creating the
>>>> API. then again, the JEE specifications weren't broken at that time so
>>>> it didn't seem necessary to cater for injecting loggers.
>>>
>>> OT: why not to starting a commons-logging 2.0 that has this feature?
>>
>> 1. ceki already did
>
> Do you speak about ILoggerFactory in slf4j or something else?
slf4j
>> 2. JCL's good enough so nothing else is ever to reach critical mass
>
> Joerg Hohwiller crusade to add a new extended interface for the Ioc friendly
> logger (e.g: IoCLogger) was not so bad.
> This could have been easy even in a minor release and it could have been
> added to api only at first.
there wasn't any realistic way to add it without breaking
compatibility. we analysed many permutations but in the JCL2.0 was
never going to fly,
>> 3. really the JCP should just get ceki to create a decent logging API
>
> true, but I don't expect a "java.util.newlogging" ever..
all it requires is energy
>> 4. i've wasted too many hundreds of hours on logging already
>
> I understood this while looking markmail for this getChildLogger issue!
> Thank you!
>
> Interesting! It's cool to know that someone else see things like me :-)
>
> http://markmail.org/message/4hlquicqcyovfv6a
> http://markmail.org/message/ynsu2uutkh2z7mfp
>
> Expecially http://markmail.org/message/3lnqomomugq3xyec
>
> I see at the end of 2005 there was a patch to add getChildLogger and a
> discussion about releasing and then add it, but I didn't found what happened
> then. I guess it simply died or you found blocking issues... it's a pity.
it would have required a major version increment. the collections hell
was bad but JCL would have been much, much worse. better to leave the
field clear for ceki.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
getChildLogger (Was: [jira] Commented: (JSIEVE-16) Singletons ->
IoC)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Mon, Sep 1, 2008 at 2:30 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On Sun, Aug 31, 2008 at 6:13 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>>> Robert Burrell Donkin ha scritto:
>
> <snip>
>
>>>>> 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.
>>> yes - that's probably the biggest mistake we made when creating the
>>> API. then again, the JEE specifications weren't broken at that time so
>>> it didn't seem necessary to cater for injecting loggers.
>> OT: why not to starting a commons-logging 2.0 that has this feature?
>
> 1. ceki already did
Do you speak about ILoggerFactory in slf4j or something else?
> 2. JCL's good enough so nothing else is ever to reach critical mass
Joerg Hohwiller crusade to add a new extended interface for the Ioc
friendly logger (e.g: IoCLogger) was not so bad.
This could have been easy even in a minor release and it could have been
added to api only at first.
> 3. really the JCP should just get ceki to create a decent logging API
true, but I don't expect a "java.util.newlogging" ever..
> 4. i've wasted too many hundreds of hours on logging already
I understood this while looking markmail for this getChildLogger issue!
Thank you!
Interesting! It's cool to know that someone else see things like me :-)
http://markmail.org/message/4hlquicqcyovfv6a
http://markmail.org/message/ynsu2uutkh2z7mfp
Expecially http://markmail.org/message/3lnqomomugq3xyec
I see at the end of 2005 there was a patch to add getChildLogger and a
discussion about releasing and then add it, but I didn't found what
happened then. I guess it simply died or you found blocking issues...
it's a pity.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (JSIEVE-16) Singletons -> IoC
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Sep 1, 2008 at 2:30 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Sun, Aug 31, 2008 at 6:13 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>>
>>> Robert Burrell Donkin ha scritto:
<snip>
>>>> 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.
>>
>> yes - that's probably the biggest mistake we made when creating the
>> API. then again, the JEE specifications weren't broken at that time so
>> it didn't seem necessary to cater for injecting loggers.
>
> OT: why not to starting a commons-logging 2.0 that has this feature?
1. ceki already did
2. JCL's good enough so nothing else is ever to reach critical mass
3. really the JCP should just get ceki to create a decent logging API
4. i've wasted too many hundreds of hours on logging already
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (JSIEVE-16) Singletons -> IoC
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Sun, Aug 31, 2008 at 6:13 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On Sun, Aug 31, 2008 at 2:59 PM, Stefano Bagnara <ap...@bago.org> 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 :-)
>
> SieveFactory is currently the (badly named) entry point. it might be
> better to have a proper factory as the entry point.
Make sense.
>>> 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.
>
> yes - that's probably the biggest mistake we made when creating the
> API. then again, the JEE specifications weren't broken at that time so
> it didn't seem necessary to cater for injecting loggers.
OT: why not to starting a commons-logging 2.0 that has this feature?
>> So if you inject a JCL logger you can't have different names in the various
>> components.
>
> jsieve doesn't need this functionality
Ok. Then plain commons logging is ok.
>> 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.
>
> i strongly suspect that JCL is the most widely used library in java.
> lots of people whinge but everyone uses it. the JEE specifications are
> mutally incompatible when it comes to classloaders. this makes it
> impossible to fix JCL or come up with anything better than it that is
> compatible with both the servlet and enterprise specifications.
>
> it's problems are well known as are the workarounds. alternative
> solutions often have better reputations because no one really uses
> them.
>
> the JCP is absolutely culpable for the whole mess. they refused to
> invite ceki onto the expert group for java.util.logging and so forced
> people to choose between log4j and java.util.logging. this forced JCL
> to be created. the JCP then decided that it was more important that
> JEE engines could do whatever they want with classloaders than
> consistency with the Java2 or servlet specifications. this caused the
> classloading hell with JCL and made it impossible to fix for both
> servlet containers and JEE containers.
Interesting summary. Didn't know the history of things. Thank you!
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (JSIEVE-16) Singletons -> IoC
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Aug 31, 2008 at 6:13 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Sun, Aug 31, 2008 at 2:59 PM, Stefano Bagnara <ap...@bago.org> 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 :-)
SieveFactory is currently the (badly named) entry point. it might be
better to have a proper factory as the entry point.
>> 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.
yes - that's probably the biggest mistake we made when creating the
API. then again, the JEE specifications weren't broken at that time so
it didn't seem necessary to cater for injecting loggers.
> So if you inject a JCL logger you can't have different names in the various
> components.
jsieve doesn't need this functionality
> 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.
i strongly suspect that JCL is the most widely used library in java.
lots of people whinge but everyone uses it. the JEE specifications are
mutally incompatible when it comes to classloaders. this makes it
impossible to fix JCL or come up with anything better than it that is
compatible with both the servlet and enterprise specifications.
it's problems are well known as are the workarounds. alternative
solutions often have better reputations because no one really uses
them.
the JCP is absolutely culpable for the whole mess. they refused to
invite ceki onto the expert group for java.util.logging and so forced
people to choose between log4j and java.util.logging. this forced JCL
to be created. the JCP then decided that it was more important that
JEE engines could do whatever they want with classloaders than
consistency with the Java2 or servlet specifications. this caused the
classloading hell with JCL and made it impossible to fix for both
servlet containers and JEE containers.
<snip>
>>> 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.
by atomic function i mean one that takes an input and produces an
output without mutating state variables. synchronisation is not
necessary providing the function has no side effects.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (JSIEVE-16) Singletons -> IoC
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Sun, Aug 31, 2008 at 2:59 PM, Stefano Bagnara <ap...@bago.org> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (JSIEVE-16) Singletons -> IoC
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Aug 31, 2008 at 2:59 PM, Stefano Bagnara <ap...@bago.org> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (JSIEVE-16) Singletons -> IoC
Posted by Stefano Bagnara <ap...@bago.org>.
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.
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.
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
> * 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).
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.
Parsing instead can be thought to happen in a single thread.
BTW take all of this only as my personal preferences/hints: you are the
one doing the job, so go ahead and I'll review your changes when you'll
commit them.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org