Mark, I think Deactivatable only works if you're using some kind of CDI extension (e.g. check whether or not the extension should install or not). For something like bean val, you need to replace the constraint validator factory w/ a custom CDI enabled one; so it becomes simply configuring validator to point to a custom one. So while Deactivatable is preferred, I don't think we can require it being used in all cases.
John On Sun, Jun 2, 2013 at 11:06 AM, Mark Struberg <[email protected]> wrote: > 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 > > >
