Enabling extensions

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Enabling extensions

Pete Muir
Administrator
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.
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: Enabling extensions

Jens Schumann
Hi Pete,

>From my experience this is a problem, especially for (partial) integration
tests within a maven based build infrastructure. In the end we had to move
certain META-INF/services/javax.enterprise.inject.spi.Extension files from
extension jars to the final deployment artifact or use System Properties
(!) to disable them;(.

Jens

On 12.09.11 16:51 "Pete Muir" <[hidden email]> wrote:

>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.
>_______________________________________________
>cdi-dev mailing list
>[hidden email]
>https://lists.jboss.org/mailman/listinfo/cdi-dev


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: [seam-dev] Enabling extensions

Mark Struberg
In reply to this post by Pete Muir
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 <[hidden email]>
> To: [hidden email]; "seam-dev >> seam-dev@lists. jboss. org Development List" <[hidden email]>
> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/seam-dev
>

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: [seam-dev] Enabling extensions

Pete Muir
Administrator
Thanks Jens & Mark, obviously a real issue!

https://issues.jboss.org/browse/CDI-157

On 12 Sep 2011, at 11:47, Mark Struberg wrote:

> 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 <[hidden email]>
>> To: [hidden email]; "seam-dev >> seam-dev@lists. jboss. org Development List" <[hidden email]>
>> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev