You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by Rudy De Busscher <rd...@gmail.com> on 2012/02/20 16:10:45 UTC
[Discuss] correct handling of multiple ClassDeactivator
Hi,
Multiple ClassDeactivator can be defined and handled by the
method org.apache.deltaspike.core.util.ClassDeactivation#initDeactivatableCacheFor
This method
uses org.apache.deltaspike.core.api.config.ConfigResolver#getAllPropertyValues
to retrieve all defined ClassDeactivator by all ConfigSources. So suppose
we have the following scenario
SystemPropertyConfigSource 400 ClassDeactivator1
PropertyFileConfigSource 100 ClassDeactivator2
Since getAllPropertyValues returns the names of the ClassDeactivator in the
order of the ordinal (thus ClassDeactivator1 first and
then ClassDeactivator2), The ClassDeactivator2 has the chance to overrule
the decision of ClassDeactivator1.
But it seems more logic to have the opposite since ClassDeactivator1 is
defined in a configSource with a higher ordinal.
*Proposition*
getAllPropertyValues() returns the values in reverse order, so
that ClassDeactivator2 comes before ClassDeactivator1.
Or when there are future usage for seen that don't break if they are
returned in reverse order, an additional parameter that controls the order.
WDYT?
--
Rudy De Busscher
http://www.c4j.be
Re: [Discuss] correct handling of multiple ClassDeactivator
Posted by Gerhard Petracek <ge...@gmail.com>.
it's fixed and tested already.
regards,
gerhard
2012/2/21 Mark Struberg <st...@yahoo.de>
> I remember that we changed exactly this behaviour at some point ^^
> We should check why we did that back then...
>
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
> > From: Rudy De Busscher <rd...@gmail.com>
> > To: deltaspike-dev@incubator.apache.org
> > Cc:
> > Sent: Monday, February 20, 2012 4:10 PM
> > Subject: [Discuss] correct handling of multiple ClassDeactivator
> >
> > Hi,
> >
> > Multiple ClassDeactivator can be defined and handled by the
> > method
> >
> org.apache.deltaspike.core.util.ClassDeactivation#initDeactivatableCacheFor
> >
> > This method
> > uses
> org.apache.deltaspike.core.api.config.ConfigResolver#getAllPropertyValues
> > to retrieve all defined ClassDeactivator by all ConfigSources. So
> suppose
> > we have the following scenario
> >
> >
> > SystemPropertyConfigSource 400 ClassDeactivator1
> > PropertyFileConfigSource 100 ClassDeactivator2
> >
> > Since getAllPropertyValues returns the names of the ClassDeactivator in
> the
> > order of the ordinal (thus ClassDeactivator1 first and
> > then ClassDeactivator2), The ClassDeactivator2 has the chance to overrule
> > the decision of ClassDeactivator1.
> >
> > But it seems more logic to have the opposite since ClassDeactivator1 is
> > defined in a configSource with a higher ordinal.
> >
> > *Proposition*
> >
> > getAllPropertyValues() returns the values in reverse order, so
> > that ClassDeactivator2 comes before ClassDeactivator1.
> >
> > Or when there are future usage for seen that don't break if they are
> > returned in reverse order, an additional parameter that controls the
> order.
> >
> > WDYT?
> >
> >
> > --
> > Rudy De Busscher
> > http://www.c4j.be
> >
>
Re: [Discuss] correct handling of multiple ClassDeactivator
Posted by Mark Struberg <st...@yahoo.de>.
I remember that we changed exactly this behaviour at some point ^^
We should check why we did that back then...
LieGrue,
strub
----- Original Message -----
> From: Rudy De Busscher <rd...@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> Cc:
> Sent: Monday, February 20, 2012 4:10 PM
> Subject: [Discuss] correct handling of multiple ClassDeactivator
>
> Hi,
>
> Multiple ClassDeactivator can be defined and handled by the
> method
> org.apache.deltaspike.core.util.ClassDeactivation#initDeactivatableCacheFor
>
> This method
> uses org.apache.deltaspike.core.api.config.ConfigResolver#getAllPropertyValues
> to retrieve all defined ClassDeactivator by all ConfigSources. So suppose
> we have the following scenario
>
>
> SystemPropertyConfigSource 400 ClassDeactivator1
> PropertyFileConfigSource 100 ClassDeactivator2
>
> Since getAllPropertyValues returns the names of the ClassDeactivator in the
> order of the ordinal (thus ClassDeactivator1 first and
> then ClassDeactivator2), The ClassDeactivator2 has the chance to overrule
> the decision of ClassDeactivator1.
>
> But it seems more logic to have the opposite since ClassDeactivator1 is
> defined in a configSource with a higher ordinal.
>
> *Proposition*
>
> getAllPropertyValues() returns the values in reverse order, so
> that ClassDeactivator2 comes before ClassDeactivator1.
>
> Or when there are future usage for seen that don't break if they are
> returned in reverse order, an additional parameter that controls the order.
>
> WDYT?
>
>
> --
> Rudy De Busscher
> http://www.c4j.be
>
Re: [Discuss] correct handling of multiple ClassDeactivator
Posted by Gerhard Petracek <ge...@gmail.com>.
hi rudy,
yes - you are right. after fixing #getPropertyValue we didn't check
#getAllPropertyValues.
i'll create a test for it (we planned to do that in any case) and fix it.
thx & regards,
gerhard
2012/2/20 Rudy De Busscher <rd...@gmail.com>
> Hi,
>
> Multiple ClassDeactivator can be defined and handled by the
> method
> org.apache.deltaspike.core.util.ClassDeactivation#initDeactivatableCacheFor
>
> This method
> uses
> org.apache.deltaspike.core.api.config.ConfigResolver#getAllPropertyValues
> to retrieve all defined ClassDeactivator by all ConfigSources. So suppose
> we have the following scenario
>
>
> SystemPropertyConfigSource 400 ClassDeactivator1
> PropertyFileConfigSource 100 ClassDeactivator2
>
> Since getAllPropertyValues returns the names of the ClassDeactivator in the
> order of the ordinal (thus ClassDeactivator1 first and
> then ClassDeactivator2), The ClassDeactivator2 has the chance to overrule
> the decision of ClassDeactivator1.
>
> But it seems more logic to have the opposite since ClassDeactivator1 is
> defined in a configSource with a higher ordinal.
>
> *Proposition*
>
> getAllPropertyValues() returns the values in reverse order, so
> that ClassDeactivator2 comes before ClassDeactivator1.
>
> Or when there are future usage for seen that don't break if they are
> returned in reverse order, an additional parameter that controls the order.
>
> WDYT?
>
>
> --
> Rudy De Busscher
> http://www.c4j.be
>
Re: [Discuss] correct handling of multiple ClassDeactivator
Posted by Rudy De Busscher <rd...@gmail.com>.
Some more information to be clear.
Suppose that both ClassDeactivator's return a value for the
method isActivated when ExcludeExtension class is passed.
ClassDeactivator1 : ExcludeExtension -> Boolean.FALSE
ClassDeactivator2 : ExcludeExtension -> Boolean.TRUE
In determining the activeState of the ExcludeExtension, this is the order
of processing
ClassDeactivator1 -> Sets state to inactive
ClassDeactivator2 -> sets state to active. (you can also the message
"Reactivation of ...." when you have the proper log level)
So a deactivator defined in a ConfigSource with a lower ordinal overwrites
the value of a deactivator defined in a ConfigSource with a higher level.
Confusion can arise due to the wrong javadoc on the method
org.apache.deltaspike.core.api.config.ConfigResolver#getAllPropertyValues.
There it is stated in ascending order.
Also the javadoc on
org.apache.deltaspike.core.spi.activation.ClassDeactivator#isActivated is
wrong.
Hopes this helps.
Regards
Rudy
On 20 February 2012 16:10, Rudy De Busscher <rd...@gmail.com> wrote:
> Hi,
>
> Multiple ClassDeactivator can be defined and handled by the
> method org.apache.deltaspike.core.util.ClassDeactivation#initDeactivatableCacheFor
>
> This method
> uses org.apache.deltaspike.core.api.config.ConfigResolver#getAllPropertyValues
> to retrieve all defined ClassDeactivator by all ConfigSources. So suppose
> we have the following scenario
>
>
> SystemPropertyConfigSource 400 ClassDeactivator1
> PropertyFileConfigSource 100 ClassDeactivator2
>
> Since getAllPropertyValues returns the names of the ClassDeactivator in
> the order of the ordinal (thus ClassDeactivator1 first and
> then ClassDeactivator2), The ClassDeactivator2 has the chance to overrule
> the decision of ClassDeactivator1.
>
> But it seems more logic to have the opposite since ClassDeactivator1 is
> defined in a configSource with a higher ordinal.
>
> *Proposition*
>
> getAllPropertyValues() returns the values in reverse order, so
> that ClassDeactivator2 comes before ClassDeactivator1.
>
> Or when there are future usage for seen that don't break if they are
> returned in reverse order, an additional parameter that controls the order.
>
> WDYT?
>
>
> --
> Rudy De Busscher
> http://www.c4j.be
>
>
--
Rudy De Busscher
http://www.c4j.be