The outcome should be failure, but it should be reported more
reasonably, and not hit an StackOverflow. Were either of these proper
services (with an interface) the proxy would have identified the
circular dependency.
On Mon, Sep 1, 2008 at 12:35 AM, Kristian Marinkovic
<[EMAIL PROTECTED]> wrote:
> Unlike Hivemind, T5 IOC creates proxies only for interfaces... this is
> intended behaviour
>
>
>
>
>
> Michel Jeanson <[EMAIL PROTECTED]>
> Gesendet von: news <[EMAIL PROTECTED]>
> 01.09.2008 00:07
> Bitte antworten an
> "Tapestry users" <users@tapestry.apache.org>
>
>
> An
> users@tapestry.apache.org
> Kopie
>
> Thema
> Circular dependencies in Tap5 IOC raise StackOverflow Error - Concrete
> classes
>
>
>
>
>
>
>
>
> I a new to T5 IOC (but not to HiveMind and Tap3, 4),
> and I encounter issues with circular dependencies.
>
> Here is my problem:
>
> I have two classes A and B with mutual dependency :
>
> public class A {
>
> private B b;
>
> public B getB() { return b; }
>
> public void setB(B b) { this.b = b; }
>
> }
>
> public class B {
>
> private A a;
>
> public A getA() { return a; }
>
> public void setA(A a) { this.a = a; }
>
> }
>
>
>
> I have built a module as follows:
>
>
> public static A buildA(@InjectService("b")B b) {
> A a = new A();
> a.setB(b);
> return a;
> }
>
> public static B buildB(@InjectService("a")A a) {
> B b = new B();
> b.setA(a);
> return b;
> }
>
>
>
> And I get a StackOverflowError
>
>
>
> Exception in thread "main" java.lang.StackOverflowError
> at java.util.regex.Pattern$6.isSatisfiedBy(Unknown
> Source)
> at java.util.regex.Pattern$6.isSatisfiedBy(Unknown
> Source)
> at java.util.regex.Pattern$CharProperty.match(Unknown
> Source)
> at java.util.regex.Pattern$GroupHead.match(Unknown
> Source)
> at java.util.regex.Pattern$Branch.match(Unknown Source)
> at java.util.regex.Pattern$Branch.match(Unknown Source)
> at java.util.regex.Pattern$Branch.match(Unknown Source)
> at java.util.regex.Pattern$BranchConn.match(Unknown
> Source)
> at java.util.regex.Pattern$GroupTail.match(Unknown
> Source)
> at java.util.regex.Pattern$Curly.match0(Unknown Source)
> at java.util.regex.Pattern$Curly.match(Unknown Source)
> at java.util.regex.Pattern$GroupHead.match(Unknown
> Source)
> at java.util.regex.Pattern$Branch.match(Unknown Source)
> at java.util.regex.Pattern$Branch.match(Unknown Source)
> at java.util.regex.Pattern$BmpCharProperty.match(Unknown
> Source)
> at java.util.regex.Pattern$Start.match(Unknown Source)
> at java.util.regex.Matcher.search(Unknown Source)
> at java.util.regex.Matcher.find(Unknown Source)
> at java.util.Formatter.parse(Unknown Source)
> at java.util.Formatter.format(Unknown Source)
> at java.util.Formatter.format(Unknown Source)
> at java.lang.String.format(Unknown Source)
> at org.apache.tapestry5.ioc.internal.util.
> MessageFormatterImpl.format(MessageFormatterImpl.java:49)
> at org.apache.tapestry5.ioc.util.
> AbstractMessages.format(AbstractMessages.java:103)
> at
> org.apache.tapestry5.ioc.internal.
> IOCMessages.creatingService(IOCMessages.java:127)
> at org.apache.tapestry5.ioc.internal.
> ModuleImpl.create(ModuleImpl.java:195)
> at org.apache.tapestry5.ioc.internal.
> ModuleImpl.findOrCreate(ModuleImpl.java:163)
> at org.apache.tapestry5.ioc.internal.
> ModuleImpl.getService(ModuleImpl.java:91)
> at org.apache.tapestry5.ioc.internal.
> RegistryImpl.getService(RegistryImpl.java:294)
> at
> org.apache.tapestry5.ioc.internal.
> ObjectLocatorImpl.getService(ObjectLocatorImpl.java:39)
> at
> org.apache.tapestry5.ioc.internal.util.
> InternalUtils.calculateParameterValue(InternalUtils.java:193)
>
> at
> org.apache.tapestry5.ioc.internal.util.
> InternalUtils.calculateParameters(InternalUtils.java:239)
> at
> org.apache.tapestry5.ioc.internal.util.
> InternalUtils.calculateParametersForMethod(InternalUtils.java:218)
> at
> org.apache.tapestry5.ioc.internal.
> ServiceBuilderMethodInvoker.createObject(ServiceBuilderMethodInvoker.java:67)
> at org.apache.tapestry5.ioc.internal.
> ModuleImpl.create(ModuleImpl.java:212)
> at org.apache.tapestry5.ioc.internal.
> ModuleImpl.findOrCreate(ModuleImpl.java:163)
> at org.apache.tapestry5.ioc.internal.
> ModuleImpl.getService(ModuleImpl.java:91)
> at org.apache.tapestry5.ioc.internal.
> RegistryImpl.getService(RegistryImpl.java:294)
> at
> org.apache.tapestry5.ioc.internal.
> ObjectLocatorImpl.getService(ObjectLocatorImpl.java:39)
> at
> org.apache.tapestry5.ioc.internal.util.
> InternalUtils.calculateParameterValue(InternalUtils.java:193)
> at
> org.apache.tapestry5.ioc.internal.util.
> InternalUtils.calculateParameters(InternalUtils.java:239)
> at
> org.apache.tapestry5.ioc.internal.util.
> InternalUtils.calculateParametersForMethod(InternalUtils.java:218)
> at
> org.apache.tapestry5.ioc.internal.
> ServiceBuilderMethodInvoker.createObject(ServiceBuilderMethodInvoker.java:67)
> at org.apache.tapestry5.ioc.internal.
> ModuleImpl.create(ModuleImpl.java:212)
> ...
> ...
> ...
>
>
> My question is: should this be considered a feature
> that concrete classes do notallow circular dependencies
> (BTW, if A and B are interfaces with AImpl and BImpl
> some implementations, everything works fine).
>
> And if this is intended, shoud this stay as it is?
> Using concrete class only might not be perfect in terms
> of theory, but it makes sense quite a few times...
>
> Thanks in advance,
>
> Michel.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
