Another thing: the functionality whether a class is activated or not must be available in our core-api module. Otherwise any 3rd party Extension would need to import the core-impl as compile dependency.
LieGrue, strub ----- Original Message ----- > From: Mark Struberg <[email protected]> > To: deltaspike <[email protected]> > Cc: > Sent: Sunday, January 22, 2012 11:09 AM > Subject: ClassDeactivator > > Hi! > > 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 apache_deltaspike.properties. > 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 . > > wdyt? > > I'll be online to work on this stuff this evening. > > LieGrue, > strub > > PS: all other areas will get their review as well >
