@John: I think your HTTP filter example is a perfect usecase for Deactivatable. In most environments the filter will be automatically picked up because of web-fragment.xml. But if you want to allow users to disable whatever the filter is for, you can let it implement Deactivateable and add some manual checks to your code that will only call chain.doFilter() if the user deactivates the class. So this would allow to disable the filter functionality although it is auto-registered by the container.
2013/6/2 Mark Struberg <[email protected]> > 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 > >> > > > -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal
