You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by Jason Porter <li...@gmail.com> on 2011/12/14 23:14:53 UTC
[DISCUSS][DELTASPIKE-9] @Requires
fyi: please check [1] before you answer.
[2] provides a short introduction as well as the basic usage.
the basic concept:
Ignore a bean if the given class(es) isn't (aren't) available.
the api:
Annotate a class with @Requires(String[])
An extension would take care of checking the classpath for the class(es)
and act accordingly to enable the bean or not.
please send
+1, +0 or -1 because...
for the basic idea as well as the basic concept
if there are >basic< objections, please also add them to [3]
[1] http://markmail.org/message/7yefspfuvtz4jvmp
[2]
http://docs.jboss.org/seam/3/3.1.0.CR1/reference/en-US/html/solder-programmingmodel.html#d0e376
[3]
https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ranking
--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp
Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling
PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
Re: [DISCUSS][DELTASPIKE-9] @Requires
Posted by Jason Porter <li...@gmail.com>.
That works for me.
Sent from my iPhone
On Dec 15, 2011, at 0:58, Mark Struberg <st...@yahoo.de> wrote:
> hiho!
>
> Yes, the problem is that some containers (resin does it; owb did it until 1.1.3) raise a DeploymentException if they cannot parse a class.
>
>
> Such a @Requires(String) would be perfectly fine if there is no bytecode link in this class. The problem is that somewhere there is some reference to those 3rd party classes. And when the class scanner hits them, he will throw a NoClassDefFound error.
>
> The behaviour in such situations only gets clarified in CDI-1.1. At least in DeltaSpike, we should just move such parts out into an own jar which is then (in itself) class code complete.
>
> Thus I'd rather say we shall postpone it. Mainly because we will hit lots of errors in current CDI containers, and thus we wont be able to provide test coverage ...
>
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Gerhard Petracek <ge...@gmail.com>
>> To: deltaspike-dev@incubator.apache.org
>> Cc:
>> Sent: Wednesday, December 14, 2011 11:41 PM
>> Subject: Re: [DISCUSS][DELTASPIKE-9] @Requires
>>
>> mark added an objection to the wiki. i agree with it -> i suggest to
>> postpone it.
>> (imo something like that should be included in cdi 1.1.)
>>
>> since @ExpressionActivated is pluggable, a deltaspike add-on can also
>> introduce it easily.
>> (for sure that depends on the upcoming discussion about
>> @ExpressionActivated)
>>
>>> if< we add it: +1 for providing it as a strategy for @ExpressionActivated
>> (via an ExpressionInterpreter)
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2011/12/14 Jason Porter <li...@gmail.com>
>>
>>> In IRC I suggested this could be a custom ExpressionInterpreter and it we
>>> wouldn't need the extra annotation. It's really for extension
>> developers
>>> anyway.
>>>
>>> I'm also thinking about it now if we need this. It's caused some
>> problems
>>> with modular servers when the initial class is loaded if those classes
>>> aren't on the classpath. Because of that I'm going to give it a +0.
>> I'm
>>> also completely fine if we leave it out. I think it would be better for
>>> extension developers to split up modules if they're are optional parts
>> of
>>> their extension(s).
>>>
>>> On Wed, Dec 14, 2011 at 15:14, Jason Porter <li...@gmail.com>
>>> wrote:
>>>
>>>> fyi: please check [1] before you answer.
>>>>
>>>> [2] provides a short introduction as well as the basic usage.
>>>>
>>>> the basic concept:
>>>> Ignore a bean if the given class(es) isn't (aren't) available.
>>>>
>>>> the api:
>>>> Annotate a class with @Requires(String[])
>>>>
>>>> An extension would take care of checking the classpath for the
>> class(es)
>>>> and act accordingly to enable the bean or not.
>>>>
>>>> please send
>>>> +1, +0 or -1 because...
>>>> for the basic idea as well as the basic concept
>>>> if there are >basic< objections, please also add them to [3]
>>>>
>>>>
>>>> [1] http://markmail.org/message/7yefspfuvtz4jvmp
>>>> [2]
>>>>
>>>
>> http://docs.jboss.org/seam/3/3.1.0.CR1/reference/en-US/html/solder-programmingmodel.html#d0e376
>>>> [3]
>>>>
>>> https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ranking
>>>>
>>>> --
>>>> Jason Porter
>>>> http://lightguard-jp.blogspot.com
>>>> http://twitter.com/lightguardjp
>>>>
>>>> Software Engineer
>>>> Open Source Advocate
>>>> Author of Seam Catch - Next Generation Java Exception Handling
>>>>
>>>> PGP key id: 926CCFF5
>>>> PGP key available at: keyserver.net, pgp.mit.edu
>>>>
>>>
>>>
>>>
>>> --
>>> Jason Porter
>>> http://lightguard-jp.blogspot.com
>>> http://twitter.com/lightguardjp
>>>
>>> Software Engineer
>>> Open Source Advocate
>>> Author of Seam Catch - Next Generation Java Exception Handling
>>>
>>> PGP key id: 926CCFF5
>>> PGP key available at: keyserver.net, pgp.mit.edu
>>>
>>
Re: [DISCUSS][DELTASPIKE-9] @Requires
Posted by Mark Struberg <st...@yahoo.de>.
hiho!
Yes, the problem is that some containers (resin does it; owb did it until 1.1.3) raise a DeploymentException if they cannot parse a class.
Such a @Requires(String) would be perfectly fine if there is no bytecode link in this class. The problem is that somewhere there is some reference to those 3rd party classes. And when the class scanner hits them, he will throw a NoClassDefFound error.
The behaviour in such situations only gets clarified in CDI-1.1. At least in DeltaSpike, we should just move such parts out into an own jar which is then (in itself) class code complete.
Thus I'd rather say we shall postpone it. Mainly because we will hit lots of errors in current CDI containers, and thus we wont be able to provide test coverage ...
LieGrue,
strub
----- Original Message -----
> From: Gerhard Petracek <ge...@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> Cc:
> Sent: Wednesday, December 14, 2011 11:41 PM
> Subject: Re: [DISCUSS][DELTASPIKE-9] @Requires
>
> mark added an objection to the wiki. i agree with it -> i suggest to
> postpone it.
> (imo something like that should be included in cdi 1.1.)
>
> since @ExpressionActivated is pluggable, a deltaspike add-on can also
> introduce it easily.
> (for sure that depends on the upcoming discussion about
> @ExpressionActivated)
>
>> if< we add it: +1 for providing it as a strategy for @ExpressionActivated
> (via an ExpressionInterpreter)
>
> regards,
> gerhard
>
>
>
> 2011/12/14 Jason Porter <li...@gmail.com>
>
>> In IRC I suggested this could be a custom ExpressionInterpreter and it we
>> wouldn't need the extra annotation. It's really for extension
> developers
>> anyway.
>>
>> I'm also thinking about it now if we need this. It's caused some
> problems
>> with modular servers when the initial class is loaded if those classes
>> aren't on the classpath. Because of that I'm going to give it a +0.
> I'm
>> also completely fine if we leave it out. I think it would be better for
>> extension developers to split up modules if they're are optional parts
> of
>> their extension(s).
>>
>> On Wed, Dec 14, 2011 at 15:14, Jason Porter <li...@gmail.com>
>> wrote:
>>
>> > fyi: please check [1] before you answer.
>> >
>> > [2] provides a short introduction as well as the basic usage.
>> >
>> > the basic concept:
>> > Ignore a bean if the given class(es) isn't (aren't) available.
>> >
>> > the api:
>> > Annotate a class with @Requires(String[])
>> >
>> > An extension would take care of checking the classpath for the
> class(es)
>> > and act accordingly to enable the bean or not.
>> >
>> > please send
>> > +1, +0 or -1 because...
>> > for the basic idea as well as the basic concept
>> > if there are >basic< objections, please also add them to [3]
>> >
>> >
>> > [1] http://markmail.org/message/7yefspfuvtz4jvmp
>> > [2]
>> >
>>
> http://docs.jboss.org/seam/3/3.1.0.CR1/reference/en-US/html/solder-programmingmodel.html#d0e376
>> > [3]
>> >
>> https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ranking
>> >
>> > --
>> > Jason Porter
>> > http://lightguard-jp.blogspot.com
>> > http://twitter.com/lightguardjp
>> >
>> > Software Engineer
>> > Open Source Advocate
>> > Author of Seam Catch - Next Generation Java Exception Handling
>> >
>> > PGP key id: 926CCFF5
>> > PGP key available at: keyserver.net, pgp.mit.edu
>> >
>>
>>
>>
>> --
>> Jason Porter
>> http://lightguard-jp.blogspot.com
>> http://twitter.com/lightguardjp
>>
>> Software Engineer
>> Open Source Advocate
>> Author of Seam Catch - Next Generation Java Exception Handling
>>
>> PGP key id: 926CCFF5
>> PGP key available at: keyserver.net, pgp.mit.edu
>>
>
Re: [DISCUSS][DELTASPIKE-9] @Requires
Posted by Gerhard Petracek <ge...@gmail.com>.
mark added an objection to the wiki. i agree with it -> i suggest to
postpone it.
(imo something like that should be included in cdi 1.1.)
since @ExpressionActivated is pluggable, a deltaspike add-on can also
introduce it easily.
(for sure that depends on the upcoming discussion about
@ExpressionActivated)
>if< we add it: +1 for providing it as a strategy for @ExpressionActivated
(via an ExpressionInterpreter)
regards,
gerhard
2011/12/14 Jason Porter <li...@gmail.com>
> In IRC I suggested this could be a custom ExpressionInterpreter and it we
> wouldn't need the extra annotation. It's really for extension developers
> anyway.
>
> I'm also thinking about it now if we need this. It's caused some problems
> with modular servers when the initial class is loaded if those classes
> aren't on the classpath. Because of that I'm going to give it a +0. I'm
> also completely fine if we leave it out. I think it would be better for
> extension developers to split up modules if they're are optional parts of
> their extension(s).
>
> On Wed, Dec 14, 2011 at 15:14, Jason Porter <li...@gmail.com>
> wrote:
>
> > fyi: please check [1] before you answer.
> >
> > [2] provides a short introduction as well as the basic usage.
> >
> > the basic concept:
> > Ignore a bean if the given class(es) isn't (aren't) available.
> >
> > the api:
> > Annotate a class with @Requires(String[])
> >
> > An extension would take care of checking the classpath for the class(es)
> > and act accordingly to enable the bean or not.
> >
> > please send
> > +1, +0 or -1 because...
> > for the basic idea as well as the basic concept
> > if there are >basic< objections, please also add them to [3]
> >
> >
> > [1] http://markmail.org/message/7yefspfuvtz4jvmp
> > [2]
> >
> http://docs.jboss.org/seam/3/3.1.0.CR1/reference/en-US/html/solder-programmingmodel.html#d0e376
> > [3]
> >
> https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ranking
> >
> > --
> > Jason Porter
> > http://lightguard-jp.blogspot.com
> > http://twitter.com/lightguardjp
> >
> > Software Engineer
> > Open Source Advocate
> > Author of Seam Catch - Next Generation Java Exception Handling
> >
> > PGP key id: 926CCFF5
> > PGP key available at: keyserver.net, pgp.mit.edu
> >
>
>
>
> --
> Jason Porter
> http://lightguard-jp.blogspot.com
> http://twitter.com/lightguardjp
>
> Software Engineer
> Open Source Advocate
> Author of Seam Catch - Next Generation Java Exception Handling
>
> PGP key id: 926CCFF5
> PGP key available at: keyserver.net, pgp.mit.edu
>
Re: [DISCUSS][DELTASPIKE-9] @Requires
Posted by Jason Porter <li...@gmail.com>.
In IRC I suggested this could be a custom ExpressionInterpreter and it we
wouldn't need the extra annotation. It's really for extension developers
anyway.
I'm also thinking about it now if we need this. It's caused some problems
with modular servers when the initial class is loaded if those classes
aren't on the classpath. Because of that I'm going to give it a +0. I'm
also completely fine if we leave it out. I think it would be better for
extension developers to split up modules if they're are optional parts of
their extension(s).
On Wed, Dec 14, 2011 at 15:14, Jason Porter <li...@gmail.com> wrote:
> fyi: please check [1] before you answer.
>
> [2] provides a short introduction as well as the basic usage.
>
> the basic concept:
> Ignore a bean if the given class(es) isn't (aren't) available.
>
> the api:
> Annotate a class with @Requires(String[])
>
> An extension would take care of checking the classpath for the class(es)
> and act accordingly to enable the bean or not.
>
> please send
> +1, +0 or -1 because...
> for the basic idea as well as the basic concept
> if there are >basic< objections, please also add them to [3]
>
>
> [1] http://markmail.org/message/7yefspfuvtz4jvmp
> [2]
> http://docs.jboss.org/seam/3/3.1.0.CR1/reference/en-US/html/solder-programmingmodel.html#d0e376
> [3]
> https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ranking
>
> --
> Jason Porter
> http://lightguard-jp.blogspot.com
> http://twitter.com/lightguardjp
>
> Software Engineer
> Open Source Advocate
> Author of Seam Catch - Next Generation Java Exception Handling
>
> PGP key id: 926CCFF5
> PGP key available at: keyserver.net, pgp.mit.edu
>
--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp
Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling
PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu