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 >
