For deactivating features we have the Deactivatable interface + config.
LieGrue, strub ----- Original Message ----- > From: John D. Ament <[email protected]> > To: [email protected] > Cc: > Sent: Sunday, 2 June 2013, 17:02 > Subject: Determining when to port functionality > > All > > Based on the bean validation thread, I figured I'd start this one off so we > can determine when it makes sense to port functionality included in later > EE specs to be added to DeltaSpike. > > For one, I think we should only consider this when it's functionality that > has been added to a spec, not for functionality that might be added to a > spec. I also think that it must be a must have that this functionality be > optional - whether it's a separate module or requires activation; so that > if someone is using the new spec they don't get burdened with the DS > implementation being in the middle. > > Second, I think we need to consider whether CODI or Seam3 provided this > functionality. Ultimately we want to get people off of these stacks and on > to DeltaSpike, It's easier to drop in a replacement library than it is to > drop in a replacement EE spec. > > Third, we need to look at the complexity to implement. Is it easy or is it > hard to do? > > Fourth that I can think of is how strong of a use case is it. Is this some > brand new programming model that will look odd to someone seeing it for the > first time? Is it simply some extra methods that can be used? > > Let's build out this list. > > John >
