Re: [seam-dev] Enabling extensions

I remember that we discussed this 2 years ago ;) In Apache MyFaces CODI we introduced an internal Deactivatable interface which by default gets implemented via public boolean isActivated() { return ClassDeactivation.isClassActivated(getClass()); } (another internal class). and in the Extension itself if(!isActivated()) { return; } A similar mechanism should be available in each bigger Extension library (not only containing 1 single CDI Extension) But would be helpful to have something like that in the standard of course! LieGrue, strub ----- Original Message ----- > From: Pete Muir <pmuir(a)redhat.com&gt; > To: cdi-dev(a)lists.jboss.org; "seam-dev >> seam-dev@lists. jboss. org Development List" <seam-dev(a)lists.jboss.org&gt; > Cc: > Sent: Monday, September 12, 2011 4:51 PM > Subject: [seam-dev] Enabling extensions > > Seam team, and others on the CDI EG, > > Looking for feedback on an issue Marius and I discussed in CDI 1.0. This is > potentially an issue - we weren't sure if people had seen it in the real > world, hopefully you may have seen feedback in the forums or at conferences. > > This relates closely to the interceptor/decorator/alternative enabling > discussion. > > Typically an extension class is packaged in a jar, along with a > META-INF/services/javax.enterprise.inject.spi.Extension file which enables it. > However, this means that an application, or another extension, has no way of > disabling extensions. > > Is this a problem, really? Or just theoretically. > _______________________________________________ > seam-dev mailing list > seam-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev >