Deactivatable is only needed for stuff which is active by default. In EE-6 a lot such 'auto-pickup' stuff got added, but there was no way to get rid of this functionality later. This is what Deactivatable is meant for.
LieGrue, strub ----- Original Message ----- > From: John D. Ament <[email protected]> > To: [email protected] > Cc: > Sent: Sunday, 2 June 2013, 20:16 > Subject: Re: Determining when to port functionality > > Christian, > > The point is more around how it should work with certain components. For > example, let's say you are creating a servlet filter to do something, e.g. > fire an event on a new HTTP request. You don't annotate it with servlet > 3.0 annotations, you do include a web-fragment.xml that maps it, and also > give instructions on how to enable it via web.xml (in case the JAR isn't in > the WAR). However this filter is also activatable. User manually maps it > via web.xml AND deactivates it. What should happen? > > John > > > On Sun, Jun 2, 2013 at 1:35 PM, Christian Kaltepoth > <[email protected]>wrote: > >> Just a small note regarding Deactivatable. AFAIK you can use it for any >> class by manually implementing checks like this: >> >> if( ClassDeactivationUtils.isActivated( this.getClass() ) ) { >> // do whatever the class is responsible for >> } >> >> >> >> >> 2013/6/2 John D. Ament <[email protected]> >> >> > 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 >> > > > >> > > >> > >> >> >> >> -- >> Christian Kaltepoth >> Blog: http://blog.kaltepoth.de/ >> Twitter: http://twitter.com/chkal >> GitHub: https://github.com/chkal >> >
