So, we didn't really talk about when the port features but instead how to make things optional. Any other thoughts?
John On Mon, Jun 3, 2013 at 1:00 AM, Christian Kaltepoth <[email protected]>wrote: > @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 >
