[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14032547#comment-14032547
]
Lance edited comment on TAP5-1611 at 6/16/14 3:39 PM:
------------------------------------------------------
Since you are requiring java.lang.Class instances in the AppModule, the classes
will be loaded into memory and will sit around in PermGen unnecessarily. Not
sure if it's an issue but this will actually fire the static initializers for
the class.
I realise it's nice to be typesafe, but there is a runtime cost for this
convenience.
In a production app, the component classes will be loaded twice (one version
for the appmodule override, and the normal plastic version).
Try adding the following to an override
{code}
package foo.bar.components;
public class OverrideComponent {
static {
System.out.println("SomeComponentOverride loaded");
}
...
}
{code}
My guess is you'll se the println twice
was (Author: uklance):
Since you are requiring java.lang.Class instances in the AppModule, the classes
will be loaded into memory and will sit around in PermGen unnecessarily. Not
sure if it's an issue but this will actually fire the static initializers for
the class.
I realise it's nice to be typesafe, but there is a runtime cost for this
convenience.
In a production app, the component classes will be loaded twice (one version
for the appmodule override, and the normal plastic version).
Try adding the following to an override
{code}
public class SomeComponentOverride {
static {
System.out.println("SomeComponentOverride loaded");
}
...
}
{code}
My guess is you'll se the println twice
> out-of-the-box way in Tapestry for replacing components
> -------------------------------------------------------
>
> Key: TAP5-1611
> URL: https://issues.apache.org/jira/browse/TAP5-1611
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Jens Breitenstein
> Assignee: Thiago H. de Paula Figueiredo
> Priority: Minor
> Labels: component, month-of-tapestry
> Fix For: 5.4
>
>
> It would be nice to allow global component replacement by a different
> component class (or derived version from the original) compared to the field
> type provided. So @InjectComponent would behave more or less like @Inject for
> services without the need of Interfaces.
> NOTE:
> current workaround is decorating ComponentInstantiatorSource
> As Thiago outlines my workaround is sub-optimal as it bases on internal
> classes which might subject to change without notice. He suggests to have an
> Service we can contribute our "overrides" to. Replaceing components would
> introduce a new level of flexibility to change implementations without
> touching tml's at all. Naturally ServiceBinder was not my suggested place for
> this new kind of "binding", seems to be a misunderstanding. From a functional
> point of view I was just thinking about something like...
> public static void bind(final ComponentBinder binder)
> {
> binder.bind(ComponentA,class, ComponentBderivedFromA.class);
> }
> ...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
