deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <>
Subject ClassDeactivator
Date Sun, 22 Jan 2012 10:09:45 GMT

I'm now reviewing the new features from last week and like to get my head around the new features.

I started alphabetically with the ClassDeactivator stuff and think I missed a few things.

a.) the ClassDeactivator only contains getDeactivatedClasses()
  This might be a problem if one likes to 'activate' a previously deactivated class, isn't?

  I'd rather move this API to "Boolean isActivated(Class)" and simplify the whole approach.

b.) we must be able to register multiplie ClassDeactivators with different ordinal. This is
actually already possible due to our way to configure them with our
  But ClassDeactivatorStorage only stores 1 single ClassDeactivator and throws away all others!
I don't like that. 

  Imo we should store all of them as we get em (ordered by their ordinal) from ConfigResolver.getAllPropertyValues(ClassDeactivator.class.getName());
and just store them.
  We don't need the DefaultClassDeactivator at all, because we just iterate over all isActivated(Class)
and take the last resolved Boolean.TRUE or Boolean.FALSE value. Any ClassDeactivator#isActivated
returning null will be ignored.

c.) DefaultClassDeactivator doesn't inherit from AbstractClassDeactivator? This is confusing
for users.

d.) I'd suggest to use move ClassDeactivation and all other those impl classes from the util
package to o.a.ds.core.impl.activation .


I'll be online to work on this stuff this evening.


PS: all other areas will get their review as well

View raw message