class Foo { @Inject Foo (Bar bar) {} } class Bar { @Inject Bar (Foo foo) {} } The spec implies that this circularity is breakable without a proxy, but I never saw a good way to do it. Any ideas? This relates to https://jira.jboss.org/jira/browse/WELD-479 which I don't believe is the intent of the spec. _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

It's the nature of @Dependent scope that two injection points never refer to the same instance, and that circularities are therefore an impossibility.

On Fri, Apr 9, 2010 at 3:29 AM, Pete Muir <pmuir(a)redhat.com&gt; wrote: > Further, Stuart and I are wondering if "(Beans with scope @Dependent never have circular dependencies.)" from 5.4 means that dependent beans are not allowed to have circular dependencies (definition error) or whether it means that they just don't have circular deps (and that the container must break the circularity. > > On 9 Apr 2010, at 09:06, Pete Muir wrote: > >> class Foo { >> >> @Inject >> Foo (Bar bar) {} >> } >> >> class Bar { >> >> @Inject >> Bar (Foo foo) {} >> >> } >> >> The spec implies that this circularity is breakable without a proxy, but I never saw a good way to do it. >> >> Any ideas? >> >> This relates to https://jira.jboss.org/jira/browse/WELD-479 which I don't believe is the intent of the spec. >> _______________________________________________ >> weld-dev mailing list >> weld-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/weld-dev > > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

On 2010-04-11, at 12:07 AM, Gavin King wrote: > It's the nature of @Dependent scope that two injection points never > refer to the same instance, and that circularities are therefore an > impossibility. Gavin, could you clarify that? From reading your comment, it seems like this use case implies unbound recursion: Foo injects Bar which in turns injects another instance of Foo (which is dependent on the first instance of Bar) which injects another instance of Bar etc.

On 2010-04-11, at 1:08 AM, Gavin King wrote: > On Sat, Apr 10, 2010 at 11:18 PM, Marius Bogoevici > <marius.bogoevici(a)gmail.com&gt; wrote: >> >> On 2010-04-11, at 12:07 AM, Gavin King wrote: >> >>> It's the nature of @Dependent scope that two injection points never >>> refer to the same instance, and that circularities are therefore an >>> impossibility. >> >> Gavin, could you clarify that? From reading your comment, it seems like this use case >> implies unbound recursion: Foo injects Bar which in turns injects another instance of Foo >> (which is dependent on the first instance of Bar) which injects another instance of Bar etc. > > Well, exactly. I mean, that's obvious from the definition of an > @Dependent object, right? > > I mean, I don't quite follow what the source of doubt here is. Section > 6.4 is *very* explicit on this. Yeah, it's not like the definition is ambiguous, but it's still good to have it summed up, I suppose - especially since it's relatively easy to create such a use case (albeit inadvertently). Incidentally, in the preamble of chapter 5 is said that : "The container is not required to support circular chains of dependencies where every bean participating in the chain has a pseudo-scope." So the question would be what happens in the case of @Dependent - it seems the spec should require a deployment error right away. Otherwise, implementors may choose to 'fix' this in a way that would violate the @Dependent definition. Also, it would be good to do the same if other pseudo-scopes are affected.

Hello All, The Weld archetypes need to be updated to reflect the latest Weld 1.0.1 release. Presently, we're using the weld-extensions-bom <dependency> <groupId>org.jboss.weld</groupId> <artifactId>weld-extensions-bom</artifactId> <version>1.0.0-CR2</version> <type>pom</type> <scope>import</scope> </dependency> The immediate issue is that the archetypes need to reflect the changes. The hairier issue is dealing with minor point release differences Now there's 2 variants of weld in the wild, via 2 Java EE containers. Glassfish has weld-1.0.0 and JBoss 6 will have 1.0.1. Should this be reflected via different BOMs? Should there be a weld-jboss-6.0.0-bom? glassfish-v3-bom? Presumably, down the road, there will be more variants as other APIs have minor point increases. If not, does anyone have suggestions for dealing with trivial variations in versions between container point releases? Thanks, Steven _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev