deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: [DISCUSS] move Deactivatable stuff to a spi package?
Date Sun, 22 Jan 2012 20:15:03 GMT
Hi!

The deactivation stuff is mostly useful if you have a more complex scenario. E.g. if Seam3.4
would disable some DS stuff and provides an own impl. But a user likes to still use the DeltaSpike
impl. Or if you have some multi-ClassLoader scenarios. But I agree that this is really only
an exceptional case. Nontheless, it was easy to add and doesn't harm to have it.

Re the spi stuff. Means we gonna move only the ClassDeactivation to the spi package?

LieGrue,
strub



----- Original Message -----
> From: Gerhard Petracek <gerhard.petracek@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> Cc: 
> Sent: Sunday, January 22, 2012 8:50 PM
> Subject: Re: [DISCUSS] move Deactivatable stuff to a spi package?
> 
> it isn't only for extensions - it's in general about the possibility to
> deactivate pre-configured internal artifacts users, add-ons, other portable
> extensions,... couldn't deactivate without it (if they have to).
> users as well asĀ  add-ons and other portable extensions can do everything
> with the interfaces. esp. users don't have to be aware of the
> 'ClassDeactivation'-helper. that was the reason for not adding it to the
> api.
> however, i agree that it's easier for add-ons and other portable extensions
> to use the helper instead of implementing it again based on the interfaces
> (that's also the difference to myfaces codi).
> 
> i still don't think that we need re-activation. if users deactivate a part
> of deltaspike (per application), they can activate it again by removing the
> deactivation they did before.
> if add-ons or other portable extensions deactivate parts of deltaspike they
> (should) do it for a good reason and it doesn't make a lot of sense (to me)
> to re-activate the original implementation again
> (without deactivating at least parts of the corresponding add-on or
> portable extension) because you have to expect problems.
> however, since the mechanism itself is in most cases just for very special
> cases and re-activation won't harm a lot, i won't block it.
> 
> summary:
> * as a compromise it's ok for me to move the parts to the
> org.apache.deltaspike.core.spi.activation package (and 
> 'ClassDeactivation'
> to org.apache.deltaspike.core.spi.activation.util).
> * -0 for the 're-activation' feature (no +0.5 or +1 because i'm 
> currently
> not convinced that we need it. no -0.5 or -1 because the possible impact is
> minimal and it doesn't introduce an additional api/spi)
> 
> regards,
> gerhard
> 
> 
> 
> 2012/1/22 Mark Struberg <struberg@yahoo.de>
> 
>>  Hi!
>> 
>>  While discussing some Deactivatable stuff with Gerhard we came across the
>>  question if we should really show all this stuff to users.
>>  I think this was also the reason why this originally got implemented in
>>  core-impl.
>> 
>>  So, I now agree that this is not intended for end-users, but highly
>>  appreciated for 'users' which write their own Extensions.
>> 
>>  I guess Extension authors might be fine if we move all those classes from
>> 
>>  org.apache.deltaspike.core.api.activation
>> 
>>  to a SPI package, e.g.
>> 
>>  org.apache.deltaspike.core.spi.activation
>> 
>>  . And if some end-user touches a spi class, then he hopefully knows that
>>  he is off-track himself ;)
>> 
>> 
>>  wdyt?
>> 
>>  LieGrue,
>>  strub
>> 
>> 
> 

Mime
View raw message