We already discussed this.
On Thu, Aug 29, 2013 at 4:26 AM, Benedikt Ritter <brit...@apache.org> wrote:
> 2013/8/27 Oliver Heger <oliver.he...@oliver-heger.de>
>
>> Am 27.08.2013 07:06, schrieb Phil Steitz:
>> > On 8/26/13 11:28 AM, Oliver Heger wrote:
>> >> Am 26.08.2013 16:18, schrieb Phil Steitz:
>> >>>
>> >>> On Aug 26, 2013, at 7:38 PM, Oliver Heger <
>> oliver.he...@oliver-heger.de> wrote:
>> >>>
>> >>>> Am 25.08.2013 18:45, schrieb Adrian Crum:
>> >>>>> +1
>> >>>>>
>> >>>>> -Adrian
>> >>>>>
>> >>>>> On 8/25/2013 9:26 AM, James Carman wrote:
>> >>>>>> AtomicReference?
>> >>>> There are multiple aspects here. One is the safe publishing of a value
>> >>>> written into the member field. This can be achieved by atomic
>> >>>> references, synchronization, or a volatile field.
>> >>>>
>> >>>> The other aspect is that such a field of a static utility class is
>> >>>> pretty global. You cannot have different values for different threads.
>> >>>>
>> >>>> So the question is, is it good design to have static utility classes
>> >>>> with state?
>> >>> Excellent point. The key question to ask is are there use cases where
>> different threads in the same JVM are really going to want different
>> default factories. I wonder if any actual user of the current code has
>> ever wanted this.
>> >>>
>> >> In this special case, I *assume* that there are hardly any concrete use
>> >> cases, but of course, we cannot be sure.
>> >>
>> >> However, there may be other examples in [configuration]. Would it make
>> >> sense to be homogeneous here, i.e. use the same design principles for
>> >> all classes?
>> >
>> > Yes and the non-static approach is certainly more flexible, so on
>> > balance I think you and James are right.
>>
>> Many thanks for the feedback! So I think I will go for the "bean-based
>> approach" then.
>>
>
> One possibility to have the best of both worlds is to create a class with
> all static methods that delegates to an instance that is hold in a static
> field. This would be for all those that want the default behavior. Those
> who need customized behavior could instanciate the delegate directly an
> configure it the way they like:
>
> public final class BeanHelperUtils {
>
> private static final BeanHelper DELEGATE = new BeanHelper(new
> DefaultBeanFactory());
>
> public static Bean someMethod() {
> return DELEGATE.someMethod();
> }
>
> }
>
> public class BeanHelper {
>
> private final BeanFactory factory;
>
> public BeanHelper(BeanFactory factory) {
> this.factory = factory;
> }
>
> public Bean someMethod() {
> factory.createBean();
> }
> }
>
> client code can either call BeanHelperUtils.someMethod()
> or create a BeanHelper with the appropriate BeanFactory instance...
>
> just my 2 cents
> Benedikt
>
>
>>
>> Oliver
>>
>> >
>> > Phil
>> >>
>> >> Oliver
>> >>
>> >>> Phil
>> >>>> For users, it may be more convenient to simply access functionality
>> >>>> through static methods, especially if the default values for static
>> >>>> member fields are reasonable for most use cases. However, such a
>> design
>> >>>> makes it impossible to use the represented functionality with
>> different
>> >>>> settings in parallel.
>> >>>>
>> >>>> Also, I am not sure whether complex class loader scenarios (e.g. an
>> >>>> application server or an OSGi container) may cause problems with the
>> >>>> static approach.
>> >>>>
>> >>>> Oliver
>> >>>>
>> >>>>>> On Sunday, August 25, 2013, Phil Steitz wrote:
>> >>>>>>
>> >>>>>>> On 8/24/13 11:33 AM, Oliver Heger wrote:
>> >>>>>>>> Hi all,
>> >>>>>>>>
>> >>>>>>>> regarding a principle design question I would like to get your
>> opinion:
>> >>>>>>>>
>> >>>>>>>> In [configuration] there are a few static utility classes. One of
>> them
>> >>>>>>>> is BeanHelper which supports the creation of beans from
>> configuration
>> >>>>>>>> data. The actual bean creation is done by a BeanFactory which can
>> be
>> >>>>>>>> configured using the static (currently unsynchronized)
>> >>>>>>>> setDefaultBeanFactory() method.
>> >>>>>>>>
>> >>>>>>>> Sebb stated correctly that this approach is thread-hostile [1]. An
>> >>>>>>>> alternative could be to make BeanHelper a non-static class which
>> can be
>> >>>>>>>> instantiated and configured per instance. This would be more
>> flexible
>> >>>>>>>> and would also simplify testing of client code (just pass in a
>> mock
>> >>>>>>>> object). The drawback is that clients now always would have to
>> >>>>>>>> create an
>> >>>>>>>> instance, so the API becomes slightly more verbose - in fact, most
>> >>>>>>>> clients will probably never have the requirement to change the
>> default
>> >>>>>>>> bean factory.
>> >>>>>>>>
>> >>>>>>>> So, the question is, what do you prefer? The static approach like
>> >>>>>>>> Object myBean = BeanHelper.createBean(...);
>> >>>>>>>>
>> >>>>>>>> or using an instance as in
>> >>>>>>>> BeanHelper helper = new BeanHelper(myFactory);
>> >>>>>>>> // or use no-args ctor for default factory
>> >>>>>>>> Object myBean = helper.createBean(...);
>> >>>>>>> Personally, I would like the static method better as a user.
>> >>>>>>> Synchronizing access to the static factory field would seem to fix
>> >>>>>>> the problem unless I am missing something. Also, I would not
>> expect
>> >>>>>>> lots of concurrent access to the getter/setter for this field in
>> >>>>>>> normal use cases , so the performance overhead of the sync would be
>> >>>>>>> immaterial. Having the setter there may also be a little easier
>> for
>> >>>>>>> dependency injection.
>> >>>>>>>
>> >>>>>>> Phil
>> >>>>>>>> TIA
>> >>>>>>>> Oliver
>> >>>>>>>>
>> >>>>>>>> [1] https://issues.apache.org/jira/browse/CONFIGURATION-486
>> >>>>>>>>
>> >>>>>>>>
>> ---------------------------------------------------------------------
>> >>>>>>>> To unsubscribe, e-mail:
>> >>>>>>>> dev-unsubscr...@commons.apache.org<javascript:;>
>> >>>>>>>> For additional commands, e-mail:
>> >>>>>>>> dev-h...@commons.apache.org<javascript:;>
>> >>>>>>>
>> ---------------------------------------------------------------------
>> >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >>>>>>> <javascript:;>
>> >>>>>>> For additional commands, e-mail:
>> >>>>>>> dev-h...@commons.apache.org<javascript:;>
>> >>>>>
>> >>>>> ---------------------------------------------------------------------
>> >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >>>> For additional commands, e-mail: dev-h...@commons.apache.org
>> >>>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >>> For additional commands, e-mail: dev-h...@commons.apache.org
>> >>>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >> For additional commands, e-mail: dev-h...@commons.apache.org
>> >>
>> >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
