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 <john.d.am...@gmail.com>
> 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 <strub...@yahoo.de> wrote:
>
> > For deactivating features we have the Deactivatable interface + config.
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> > ----- Original Message -----
> > > From: John D. Ament <john.d.am...@gmail.com>
> > > To: dev@deltaspike.apache.org
> > > 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
