Mailing-List: contact deltaspike-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: deltaspike-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.de;
  h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=aBpcyBxaJVR9FMx1pjffOyRJcxXcQ/gSOL5QnCOKtXI3xTEpXACGCs4ZEzZZlclSsnEivZm8tEvwlOLE+pXWbzXa/XLpFWilh0PIRgPLBCN2DoffcQxJotXgcisGlPcFx04BH8eBFqpjJA81z2/iSW88OMyTeX5jmyejxz15lk0=;
References: <1327254825.48536.YahooMailNeo@web27804.mail.ukl.yahoo.com>
 <CAGJtJfFX3d2owXv3TGw6kcjn2nVnw539MS7=jQg=X-dg4g7nbA@mail.gmail.com>
Message-ID: <1327263303.33630.YahooMailNeo@web27802.mail.ukl.yahoo.com>
Date: Sun, 22 Jan 2012 20:15:03 +0000 (GMT)
From: Mark Struberg <struberg@yahoo.de>
Reply-To: Mark Struberg <struberg@yahoo.de>
Subject: Re: [DISCUSS] move Deactivatable stuff to a spi package?
To: "deltaspike-dev@incubator.apache.org"
 <deltaspike-dev@incubator.apache.org>
In-Reply-To: 
 <CAGJtJfFX3d2owXv3TGw6kcjn2nVnw539MS7=jQg=X-dg4g7nbA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi!=0A=0AThe 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 som=
e multi-ClassLoader scenarios. But I agree that this is really only an exce=
ptional case. Nontheless, it was easy to add and doesn't harm to have it.=
=0A=0ARe the spi stuff. Means we gonna move only the ClassDeactivation to t=
he spi package?=0A=0ALieGrue,=0Astrub=0A=0A=0A=0A----- Original Message ---=
--=0A> From: Gerhard Petracek <gerhard.petracek@gmail.com>=0A> To: deltaspi=
ke-dev@incubator.apache.org=0A> Cc: =0A> Sent: Sunday, January 22, 2012 8:5=
0 PM=0A> Subject: Re: [DISCUSS] move Deactivatable stuff to a spi package?=
=0A> =0A> it isn't only for extensions - it's in general about the possibil=
ity to=0A> deactivate pre-configured internal artifacts users, add-ons, oth=
er portable=0A> extensions,... couldn't deactivate without it (if they have=
 to).=0A> users as well as=A0 add-ons and other portable extensions can do =
everything=0A> with the interfaces. esp. users don't have to be aware of th=
e=0A> 'ClassDeactivation'-helper. that was the reason for not adding it to =
the=0A> api.=0A> however, i agree that it's easier for add-ons and other po=
rtable extensions=0A> to use the helper instead of implementing it again ba=
sed on the interfaces=0A> (that's also the difference to myfaces codi).=0A>=
 =0A> i still don't think that we need re-activation. if users deactivate a=
 part=0A> of deltaspike (per application), they can activate it again by re=
moving the=0A> deactivation they did before.=0A> if add-ons or other portab=
le extensions deactivate parts of deltaspike they=0A> (should) do it for a =
good reason and it doesn't make a lot of sense (to me)=0A> to re-activate t=
he original implementation again=0A> (without deactivating at least parts o=
f the corresponding add-on or=0A> portable extension) because you have to e=
xpect problems.=0A> however, since the mechanism itself is in most cases ju=
st for very special=0A> cases and re-activation won't harm a lot, i won't b=
lock it.=0A> =0A> summary:=0A> * as a compromise it's ok for me to move the=
 parts to the=0A> org.apache.deltaspike.core.spi.activation package (and =
=0A> 'ClassDeactivation'=0A> to org.apache.deltaspike.core.spi.activation.u=
til).=0A> * -0 for the 're-activation' feature (no +0.5 or +1 because i'm =
=0A> currently=0A> not convinced that we need it. no -0.5 or -1 because the=
 possible impact is=0A> minimal and it doesn't introduce an additional api/=
spi)=0A> =0A> regards,=0A> gerhard=0A> =0A> =0A> =0A> 2012/1/22 Mark Strube=
rg <struberg@yahoo.de>=0A> =0A>>  Hi!=0A>> =0A>>  While discussing some Dea=
ctivatable stuff with Gerhard we came across the=0A>>  question if we shoul=
d really show all this stuff to users.=0A>>  I think this was also the reas=
on why this originally got implemented in=0A>>  core-impl.=0A>> =0A>>  So, =
I now agree that this is not intended for end-users, but highly=0A>>  appre=
ciated for 'users' which write their own Extensions.=0A>> =0A>>  I guess Ex=
tension authors might be fine if we move all those classes from=0A>> =0A>> =
 org.apache.deltaspike.core.api.activation=0A>> =0A>>  to a SPI package, e.=
g.=0A>> =0A>>  org.apache.deltaspike.core.spi.activation=0A>> =0A>>  . And =
if some end-user touches a spi class, then he hopefully knows that=0A>>  he=
 is off-track himself ;)=0A>> =0A>> =0A>>  wdyt?=0A>> =0A>>  LieGrue,=0A>> =
 strub=0A>> =0A>> =0A>