[cdi-dev] [seam-dev] Enabling extensions

Mark Struberg struberg at yahoo.de
Mon Sep 12 11:47:02 EDT 2011


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 at redhat.com>
> To: cdi-dev at lists.jboss.org; "seam-dev >> seam-dev at lists. jboss. org Development List" <seam-dev at lists.jboss.org>
> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>



More information about the cdi-dev mailing list