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 <[email protected]> > To: [email protected] > 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 <[email protected]> > >> 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 <[email protected]> >> 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 >> >
