You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by "John D. Ament" <jo...@gmail.com> on 2013/06/02 17:02:09 UTC
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
Re: Determining when to port functionality
Posted by "John D. Ament" <jo...@gmail.com>.
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
<ch...@kaltepoth.de>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 <st...@yahoo.de>
>
> > 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 <jo...@gmail.com>
> > > To: dev@deltaspike.apache.org
> > > 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
> > > <ch...@kaltepoth.de>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 <jo...@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
> > > <st...@yahoo.de>
> > >> wrote:
> > >> >
> > >> > > For deactivating features we have the Deactivatable interface +
> > > config.
> > >> > >
> > >> > >
> > >> > > LieGrue,
> > >> > > strub
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > ----- Original Message -----
> > >> > > > From: John D. Ament <jo...@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
> > >>
> > >
> >
>
>
>
> --
> Christian Kaltepoth
> Blog: http://blog.kaltepoth.de/
> Twitter: http://twitter.com/chkal
> GitHub: https://github.com/chkal
>
Re: Determining when to port functionality
Posted by Christian Kaltepoth <ch...@kaltepoth.de>.
@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 <st...@yahoo.de>
> 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 <jo...@gmail.com>
> > To: dev@deltaspike.apache.org
> > 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
> > <ch...@kaltepoth.de>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 <jo...@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
> > <st...@yahoo.de>
> >> wrote:
> >> >
> >> > > For deactivating features we have the Deactivatable interface +
> > config.
> >> > >
> >> > >
> >> > > LieGrue,
> >> > > strub
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > ----- Original Message -----
> >> > > > From: John D. Ament <jo...@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
> >>
> >
>
--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal
Re: Determining when to port functionality
Posted by Mark Struberg <st...@yahoo.de>.
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 <jo...@gmail.com>
> To: dev@deltaspike.apache.org
> 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
> <ch...@kaltepoth.de>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 <jo...@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
> <st...@yahoo.de>
>> wrote:
>> >
>> > > For deactivating features we have the Deactivatable interface +
> config.
>> > >
>> > >
>> > > LieGrue,
>> > > strub
>> > >
>> > >
>> > >
>> > >
>> > > ----- Original Message -----
>> > > > From: John D. Ament <jo...@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
>>
>
Re: Determining when to port functionality
Posted by "John D. Ament" <jo...@gmail.com>.
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
<ch...@kaltepoth.de>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 <jo...@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 <st...@yahoo.de>
> wrote:
> >
> > > For deactivating features we have the Deactivatable interface + config.
> > >
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >
> > >
> > > ----- Original Message -----
> > > > From: John D. Ament <jo...@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
>
Re: Determining when to port functionality
Posted by Christian Kaltepoth <ch...@kaltepoth.de>.
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 <jo...@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 <st...@yahoo.de> wrote:
>
> > For deactivating features we have the Deactivatable interface + config.
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> > ----- Original Message -----
> > > From: John D. Ament <jo...@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
Re: Determining when to port functionality
Posted by "John D. Ament" <jo...@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 <st...@yahoo.de> wrote:
> For deactivating features we have the Deactivatable interface + config.
>
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
> > From: John D. Ament <jo...@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
> >
>
Re: Determining when to port functionality
Posted by Mark Struberg <st...@yahoo.de>.
For deactivating features we have the Deactivatable interface + config.
LieGrue,
strub
----- Original Message -----
> From: John D. Ament <jo...@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
>