You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Michel Jeanson <ki...@jubii.fr> on 2008/09/01 00:07:40 UTC
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Circular dependencies in Tap5 IOC raise StackOverflow Error - Concrete classes
Posted by Howard Lewis Ship <hl...@gmail.com>.
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
<kr...@porsche.co.at> wrote:
> Unlike Hivemind, T5 IOC creates proxies only for interfaces... this is
> intended behaviour
>
>
>
>
>
> Michel Jeanson <ki...@jubii.fr>
> Gesendet von: news <ne...@ger.gmane.org>
> 01.09.2008 00:07
> Bitte antworten an
> "Tapestry users" <us...@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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Circular dependencies in Tap5 IOC raise StackOverflow Error - Concrete classes
Posted by Christian Edward Gruber <ch...@gmail.com>.
Might be good to do an on-registration circular dependency check to
ensure that services cannot be defined if they would cause a cycle.
I'd open a JIRA but I'm laaaaazy. (Ok, I'll open one tomorrow. I'm
going to sleep now)
Christian.
On 1-Sep-08, at 03:35 , Kristian Marinkovic wrote:
> Unlike Hivemind, T5 IOC creates proxies only for interfaces... this is
> intended behaviour
>
>
>
>
>
> Michel Jeanson <ki...@jubii.fr>
> Gesendet von: news <ne...@ger.gmane.org>
> 01.09.2008 00:07
> Bitte antworten an
> "Tapestry users" <us...@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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Circular dependencies in Tap5 IOC raise StackOverflow Error - Concrete
classes
Posted by Kristian Marinkovic <kr...@porsche.co.at>.
Unlike Hivemind, T5 IOC creates proxies only for interfaces... this is
intended behaviour
Michel Jeanson <ki...@jubii.fr>
Gesendet von: news <ne...@ger.gmane.org>
01.09.2008 00:07
Bitte antworten an
"Tapestry users" <us...@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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org