You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Andreas Pardeike <ap...@fsys.se> on 2009/03/20 13:08:31 UTC
5.0.18 - 5.1.0.1 upgrade problems
Hi,
two problems so far. Can somebody help me migrating those?
1) ComponentActionRequestHandler
--------------------------------
public void
contributeComponentActionRequestHandler
(OrderedConfiguration<ComponentEventRequestFilter> configuration,
ComponentEventRequestFilter accessController)
{
configuration.add("ComponentAccessController", accessController,
"before:*");
}
---> Contribution
se
.fsys
.klubb
.services
.AppModule
.contributeComponentActionRequestHandler(OrderedConfiguration,
ComponentEventRequestFilter) (at AppModule.java:68) is for service
'ComponentActionRequestHandler', which does not exist.
2) ComponentResources
---------------------
public class ExceptionHandler implements RequestExceptionHandler
{
public ExceptionHandler(RequestPageCache pageCache,
PageResponseRenderer renderer, final Logger logger, final Response
response, final ComponentClassResolver resolver, final
ComponentResources componentResources, @Inject
@Symbol(SymbolConstants.PRODUCTION_MODE) boolean productionMode)
{
}
}
---> [ERROR] Registry No service implements the interface
org.apache.tapestry5.ComponentResources.
[ERROR] Registry Operations trace:
[ERROR] Registry [ 1] Realizing service ExceptionHandler
[ERROR] Registry [ 2] Invoking
se.fsys.klubb.core.handlers.ExceptionHandler(RequestPageCache,
PageResponseRenderer, Logger, Response, ComponentClassResolver,
ComponentResources, boolean) (at ExceptionHandler.java:32) via
se.fsys.klubb.services.TweaksModule.bind(ServiceBinder) (at
TweaksModule.java:60)
[ERROR] Registry [ 3] Determining injection value for parameter #6
(org.apache.tapestry5.ComponentResources)
[ERROR] Registry [ 4] Resolving object of type
org.apache.tapestry5.ComponentResources using MasterObjectProvider
[ERROR] ExceptionHandler Construction of service ExceptionHandler
failed: Error invoking constructor
se.fsys.klubb.core.handlers.ExceptionHandler(RequestPageCache,
PageResponseRenderer, Logger, Response, ComponentClassResolver,
ComponentResources, boolean) (at ExceptionHandler.java:32) via
se.fsys.klubb.services.TweaksModule.bind(ServiceBinder) (at
TweaksModule.java:60) (for service 'ExceptionHandler'): No service
implements the interface org.apache.tapestry5.ComponentResources.
/Andreas Pardeike
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: 5.0.18 - 5.1.0.1 upgrade problems
Posted by Ville Virtanen <vi...@cerion.fi>.
Ok,
now when you put it that way it is clear :)
- Ville
Robert Zeigler wrote:
>
> This is already clear.
> Stuff in org.apache.tapestry5.services,
> org.apache.tapestry5.ioc.services, etc. can be injected. (For that
> matter, org.apache.tapestry5.internal.services classes can be injected
> as well, but that's not advised). Anything else can't be injected
> into other services.
> ComonentResources is in package org.apache.tapestry5. Clear /not/ a
> service.
>
> What's more is that it makes absolutely no sense to inject into a
> service; ComponentResource for which component, in particular?
>
> Robert
>
> On Mar 21, 2009, at 3/216:05 AM , Ville Virtanen wrote:
>
>>
>> It would be great if the documentation (javadoc) for an example
>> would state
>> this clearly in every service interface documentation IF the service
>> cannot
>> be used in another service.
>>
>> Now you just need to know which services are "special".
>>
>> - Ville
>>
>>
>> Thiago H. de Paula Figueiredo wrote:
>>>
>>> On Fri, Mar 20, 2009 at 10:53 AM, Andreas Pardeike <ap...@fsys.se>
>>> wrote:
>>>> Thiago,
>>>
>>> Hi!
>>> Thinking further, ComponentResources is not a service, but something
>>> that has special injection logic that only handles components, pages
>>> and mixins. It is a way of a component, page or mixin to access all
>>> the methods and properties Tapestry adds to them. Thus, I don't know
>>> how to inject it in a service.
>>>
>>> You can file a JIRA asking for some way of doing that.
>>>
>>> --
>>> Thiago
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/5.0.18---5.1.0.1-upgrade-problems-tp22619066p22634872.html
>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
--
View this message in context: http://www.nabble.com/5.0.18---5.1.0.1-upgrade-problems-tp22619066p22654930.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: 5.0.18 - 5.1.0.1 upgrade problems
Posted by Massimo Lusetti <ml...@gmail.com>.
On Tue, Mar 24, 2009 at 2:20 PM, Robert Zeigler <ro...@scazdl.org> wrote:
> maybe we ought to have cleaner, public support for it...
Wise words. It's since day one i start to write authentication and
authorization logic that i stumble across this.
Ciao
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: 5.0.18 - 5.1.0.1 upgrade problems
Posted by Howard Lewis Ship <hl...@gmail.com>.
Exactly, and the actually implementation (already checked in)
documents this distinction.
On Tue, Mar 24, 2009 at 10:18 AM, Robert Zeigler <ro...@scazdl.org> wrote:
> +1.
>
> I assume the difference between createPageRenderLink and
> createPageRenderLinkWithContext is that if the context is empty in with
> context, you're going to override the page's passivate context with an empty
> context, whereas with createPageRenderLink, you let the page supply it's own
> context?
>
> Robert
>
> On Mar 24, 2009, at 3/2411:40 AM , Howard Lewis Ship wrote:
>
>> I think there needs to be a facade service to make this easier: a
>> PageLinkSource.
>>
>> public interface PageRenderLinkSource
>> {
>> Link createPageRenderLink(String pageName);
>>
>> Link createPageRenderLinkWithContext(String pageName, Object... context);
>>
>> Link createPageRenderLink(Class pageClass);
>>
>> Link createPageRenderLinkWithContet(Class pageClass, Object... context);
>> }
>>
>>
>>
>> On Tue, Mar 24, 2009 at 6:20 AM, Robert Zeigler <ro...@scazdl.org>
>> wrote:
>>>
>>> I think that's ugly. :)
>>>
>>> Consider:
>>> componentSource
>>> .getPage
>>> (Index.class).getComponentResources().createPageLink(Index.class,true);
>>>
>>> Personally, I get suspicious of call chains nested more than about
>>> two-deep... smells of tight coupling.
>>>
>>> Ultimately, componentResources.createPageLink calls into LinkSource,
>>> which
>>> calls into ComponentEvenLinkEncoder to create the link. *shrug*.
>>> Why not bypass the nastiness and go straight to
>>> ComponentEventLinkEncoder?
>>> It /is/ a public service, after all... Personally, though, I wonder if it
>>> should be the other way around: ComponentEventLinkEncoder really exposes
>>> too
>>> much of the internal "guts" of how tapestry "thinks" about requests: page
>>> names, nested component ids, etc. (In the form of the
>>> PageRequestParameters
>>> and ComponentEventRequestParameters objects. In that regard, using
>>> component resources is "correct" because it "hides" all of the gory
>>> details...
>>>
>>> Except that it still requires an ugly rats' nest of method calls.
>>> Creating
>>> links to pages from within services seems like such a common paradigm
>>> (redirecting to the login page on authentication failure, for example);
>>> maybe we ought to have cleaner, public support for it...
>>>
>>> Robert
>>>
>>>
>>>
>>> On Mar 23, 2009, at 3/2310:47 AM , Howard Lewis Ship wrote:
>>>
>>>> The correct approach is to use ComponentSource
>>>>
>>>>
>>>> (http://tapestry.formos.com/nightly/tapestry5/apidocs/org/apache/tapestry5/services/ComponentSource.html)
>>>> to acquire a page.
>>>>
>>>> You can then get its ComponentResources and generate a page render
>>>> Link from the resources.
>>>>
>>>> On Mon, Mar 23, 2009 at 8:36 AM, Massimo Lusetti <ml...@gmail.com>
>>>> wrote:
>>>>>
>>>>> On Mon, Mar 23, 2009 at 4:29 PM, Robert Zeigler <ro...@scazdl.org>
>>>>> wrote:
>>>>>
>>>>>> If you want to stick with public services, and you're using 5.1, you
>>>>>> can
>>>>>> use:
>>>>>>
>>>>>>
>>>>>> http://tapestry.formos.com/nightly/tapestry5/apidocs/org/apache/tapestry5/services/ComponentEventLinkEncoder.html
>>>>>>
>>>>>> I don't think it's quite as convenient to use as LinkSource, but at
>>>>>> least
>>>>>> it's public. :)
>>>>>
>>>>> I think that's the better bet we can have and that has been made for
>>>>> similar use cases.
>>>>>
>>>>> --
>>>>> Massimo
>>>>> http://meridio.blogspot.com
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
> ---------------------------------------------------------------------
> 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: 5.0.18 - 5.1.0.1 upgrade problems
Posted by Robert Zeigler <ro...@scazdl.org>.
+1.
I assume the difference between createPageRenderLink and
createPageRenderLinkWithContext is that if the context is empty in
with context, you're going to override the page's passivate context
with an empty context, whereas with createPageRenderLink, you let the
page supply it's own context?
Robert
On Mar 24, 2009, at 3/2411:40 AM , Howard Lewis Ship wrote:
> I think there needs to be a facade service to make this easier: a
> PageLinkSource.
>
> public interface PageRenderLinkSource
> {
> Link createPageRenderLink(String pageName);
>
> Link createPageRenderLinkWithContext(String pageName, Object...
> context);
>
> Link createPageRenderLink(Class pageClass);
>
> Link createPageRenderLinkWithContet(Class pageClass, Object...
> context);
> }
>
>
>
> On Tue, Mar 24, 2009 at 6:20 AM, Robert Zeigler <ro...@scazdl.org>
> wrote:
>> I think that's ugly. :)
>>
>> Consider:
>> componentSource
>> .getPage
>> (Index
>> .class).getComponentResources().createPageLink(Index.class,true);
>>
>> Personally, I get suspicious of call chains nested more than about
>> two-deep... smells of tight coupling.
>>
>> Ultimately, componentResources.createPageLink calls into
>> LinkSource, which
>> calls into ComponentEvenLinkEncoder to create the link. *shrug*.
>> Why not bypass the nastiness and go straight to
>> ComponentEventLinkEncoder?
>> It /is/ a public service, after all... Personally, though, I wonder
>> if it
>> should be the other way around: ComponentEventLinkEncoder really
>> exposes too
>> much of the internal "guts" of how tapestry "thinks" about
>> requests: page
>> names, nested component ids, etc. (In the form of the
>> PageRequestParameters
>> and ComponentEventRequestParameters objects. In that regard, using
>> component resources is "correct" because it "hides" all of the gory
>> details...
>>
>> Except that it still requires an ugly rats' nest of method calls.
>> Creating
>> links to pages from within services seems like such a common paradigm
>> (redirecting to the login page on authentication failure, for
>> example);
>> maybe we ought to have cleaner, public support for it...
>>
>> Robert
>>
>>
>>
>> On Mar 23, 2009, at 3/2310:47 AM , Howard Lewis Ship wrote:
>>
>>> The correct approach is to use ComponentSource
>>>
>>> (http://tapestry.formos.com/nightly/tapestry5/apidocs/org/apache/tapestry5/services/ComponentSource.html
>>> )
>>> to acquire a page.
>>>
>>> You can then get its ComponentResources and generate a page render
>>> Link from the resources.
>>>
>>> On Mon, Mar 23, 2009 at 8:36 AM, Massimo Lusetti
>>> <ml...@gmail.com>
>>> wrote:
>>>>
>>>> On Mon, Mar 23, 2009 at 4:29 PM, Robert Zeigler
>>>> <ro...@scazdl.org>
>>>> wrote:
>>>>
>>>>> If you want to stick with public services, and you're using 5.1,
>>>>> you can
>>>>> use:
>>>>>
>>>>> http://tapestry.formos.com/nightly/tapestry5/apidocs/org/apache/tapestry5/services/ComponentEventLinkEncoder.html
>>>>>
>>>>> I don't think it's quite as convenient to use as LinkSource, but
>>>>> at
>>>>> least
>>>>> it's public. :)
>>>>
>>>> I think that's the better bet we can have and that has been made
>>>> for
>>>> similar use cases.
>>>>
>>>> --
>>>> Massimo
>>>> http://meridio.blogspot.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>>
>> ---------------------------------------------------------------------
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: 5.0.18 - 5.1.0.1 upgrade problems
Posted by Howard Lewis Ship <hl...@gmail.com>.
I think there needs to be a facade service to make this easier: a
PageLinkSource.
public interface PageRenderLinkSource
{
Link createPageRenderLink(String pageName);
Link createPageRenderLinkWithContext(String pageName, Object... context);
Link createPageRenderLink(Class pageClass);
Link createPageRenderLinkWithContet(Class pageClass, Object... context);
}
On Tue, Mar 24, 2009 at 6:20 AM, Robert Zeigler <ro...@scazdl.org> wrote:
> I think that's ugly. :)
>
> Consider:
> componentSource
> .getPage
> (Index.class).getComponentResources().createPageLink(Index.class,true);
>
> Personally, I get suspicious of call chains nested more than about
> two-deep... smells of tight coupling.
>
> Ultimately, componentResources.createPageLink calls into LinkSource, which
> calls into ComponentEvenLinkEncoder to create the link. *shrug*.
> Why not bypass the nastiness and go straight to ComponentEventLinkEncoder?
> It /is/ a public service, after all... Personally, though, I wonder if it
> should be the other way around: ComponentEventLinkEncoder really exposes too
> much of the internal "guts" of how tapestry "thinks" about requests: page
> names, nested component ids, etc. (In the form of the PageRequestParameters
> and ComponentEventRequestParameters objects. In that regard, using
> component resources is "correct" because it "hides" all of the gory
> details...
>
> Except that it still requires an ugly rats' nest of method calls. Creating
> links to pages from within services seems like such a common paradigm
> (redirecting to the login page on authentication failure, for example);
> maybe we ought to have cleaner, public support for it...
>
> Robert
>
>
>
> On Mar 23, 2009, at 3/2310:47 AM , Howard Lewis Ship wrote:
>
>> The correct approach is to use ComponentSource
>>
>> (http://tapestry.formos.com/nightly/tapestry5/apidocs/org/apache/tapestry5/services/ComponentSource.html)
>> to acquire a page.
>>
>> You can then get its ComponentResources and generate a page render
>> Link from the resources.
>>
>> On Mon, Mar 23, 2009 at 8:36 AM, Massimo Lusetti <ml...@gmail.com>
>> wrote:
>>>
>>> On Mon, Mar 23, 2009 at 4:29 PM, Robert Zeigler <ro...@scazdl.org>
>>> wrote:
>>>
>>>> If you want to stick with public services, and you're using 5.1, you can
>>>> use:
>>>>
>>>> http://tapestry.formos.com/nightly/tapestry5/apidocs/org/apache/tapestry5/services/ComponentEventLinkEncoder.html
>>>>
>>>> I don't think it's quite as convenient to use as LinkSource, but at
>>>> least
>>>> it's public. :)
>>>
>>> I think that's the better bet we can have and that has been made for
>>> similar use cases.
>>>
>>> --
>>> Massimo
>>> http://meridio.blogspot.com
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
> ---------------------------------------------------------------------
> 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: 5.0.18 - 5.1.0.1 upgrade problems
Posted by Robert Zeigler <ro...@scazdl.org>.
Yes, event links are a different animal (at this point).
That's evident when comparing ComponentEventRequestParameters and
PageRenderRequestParameters.
For component event links, then, it makes some sense to fetch the
particular component instance and its resources, and generate the link
that way.
But, let's be realistic... what is the likelihood that a service will
generate a component event link? I can think of scenarios, but... the
vast majority of use cases are handled by a simple, public service
that wants you to give it a page class (or perhaps a page name as a
string) with perhaps an activation context.
Robert
On Mar 24, 2009, at 3/2410:33 AM , Fernando Padilla wrote:
> I believe for page links, there is no difference. And you can just
> get the LinkFactory.
>
> For EventLinks, now it starts to get different because you are
> targetting both a page and a component ( which can be on a different
> page ). I'm still not a master on figuring this out, but I know
> what to look out for:
>
> pagelink:
>
> http://server/page/pagecontext
>
> eventlink:
>
> http://server/pagewithcomponent:component/eventcontext?t:ac=pagecontext&t:cp=pagetorender
>
>
>
> Andreas Pardeike wrote:
>> On 24 mar 2009, at 14.20, Robert Zeigler wrote:
>>> I think that's ugly. :)
>>>
>>> Consider:
>>> componentSource
>>> .getPage
>>> (Index
>>> .class).getComponentResources().createPageLink(Index.class,true);
>>>
>>> Personally, I get suspicious of call chains nested more than about
>>> two-deep... smells of tight coupling.
>>>
>>> Ultimately, componentResources.createPageLink calls into
>>> LinkSource, which calls into ComponentEvenLinkEncoder to create
>>> the link. *shrug*.
>>> Why not bypass the nastiness and go straight to
>>> ComponentEventLinkEncoder? It /is/ a public service, after all...
>>> Personally, though, I wonder if it should be the other way around:
>>> ComponentEventLinkEncoder really exposes too much of the internal
>>> "guts" of how tapestry "thinks" about requests: page names, nested
>>> component ids, etc. (In the form of the PageRequestParameters and
>>> ComponentEventRequestParameters objects. In that regard, using
>>> component resources is "correct" because it "hides" all of the
>>> gory details...
>>>
>>> Except that it still requires an ugly rats' nest of method calls.
>>> Creating links to pages from within services seems like such a
>>> common paradigm (redirecting to the login page on authentication
>>> failure, for example); maybe we ought to have cleaner, public
>>> support for it...
>> I totally agree with Robert. Plus, what is the difference between:
>> componentSource
>> .getPage
>> (XXX.class).getComponentResources().createPageLink(XXX.class,true);
>> componentSource
>> .getPage
>> (YYY.class).getComponentResources().createPageLink(XXX.class,true);
>> Will I still get the same link? If so, why do I need to get a page
>> in first place?
>> /Andreas
>> ---------------------------------------------------------------------
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: 5.0.18 - 5.1.0.1 upgrade problems
Posted by Fernando Padilla <fe...@alum.mit.edu>.
I believe for page links, there is no difference. And you can just get
the LinkFactory.
For EventLinks, now it starts to get different because you are
targetting both a page and a component ( which can be on a different
page ). I'm still not a master on figuring this out, but I know what to
look out for:
pagelink:
http://server/page/pagecontext
eventlink:
http://server/pagewithcomponent:component/eventcontext?t:ac=pagecontext&t:cp=pagetorender
Andreas Pardeike wrote:
> On 24 mar 2009, at 14.20, Robert Zeigler wrote:
>
>> I think that's ugly. :)
>>
>> Consider:
>> componentSource
>> .getPage
>> (Index
>> .class).getComponentResources().createPageLink(Index.class,true);
>>
>> Personally, I get suspicious of call chains nested more than about
>> two-deep... smells of tight coupling.
>>
>> Ultimately, componentResources.createPageLink calls into LinkSource,
>> which calls into ComponentEvenLinkEncoder to create the link. *shrug*.
>> Why not bypass the nastiness and go straight to
>> ComponentEventLinkEncoder? It /is/ a public service, after all...
>> Personally, though, I wonder if it should be the other way around:
>> ComponentEventLinkEncoder really exposes too much of the internal
>> "guts" of how tapestry "thinks" about requests: page names, nested
>> component ids, etc. (In the form of the PageRequestParameters and
>> ComponentEventRequestParameters objects. In that regard, using
>> component resources is "correct" because it "hides" all of the gory
>> details...
>>
>> Except that it still requires an ugly rats' nest of method calls.
>> Creating links to pages from within services seems like such a common
>> paradigm (redirecting to the login page on authentication failure, for
>> example); maybe we ought to have cleaner, public support for it...
>
> I totally agree with Robert. Plus, what is the difference between:
>
> componentSource.getPage(XXX.class).getComponentResources().createPageLink(XXX.class,true);
>
> componentSource.getPage(YYY.class).getComponentResources().createPageLink(XXX.class,true);
>
>
> Will I still get the same link? If so, why do I need to get a page in
> first place?
>
> /Andreas
>
> ---------------------------------------------------------------------
> 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: 5.0.18 - 5.1.0.1 upgrade problems
Posted by Andreas Pardeike <ap...@fsys.se>.
On 24 mar 2009, at 14.20, Robert Zeigler wrote:
> I think that's ugly. :)
>
> Consider:
> componentSource
> .getPage
> (Index
> .class).getComponentResources().createPageLink(Index.class,true);
>
> Personally, I get suspicious of call chains nested more than about
> two-deep... smells of tight coupling.
>
> Ultimately, componentResources.createPageLink calls into LinkSource,
> which calls into ComponentEvenLinkEncoder to create the link. *shrug*.
> Why not bypass the nastiness and go straight to
> ComponentEventLinkEncoder? It /is/ a public service, after all...
> Personally, though, I wonder if it should be the other way around:
> ComponentEventLinkEncoder really exposes too much of the internal
> "guts" of how tapestry "thinks" about requests: page names, nested
> component ids, etc. (In the form of the PageRequestParameters and
> ComponentEventRequestParameters objects. In that regard, using
> component resources is "correct" because it "hides" all of the gory
> details...
>
> Except that it still requires an ugly rats' nest of method calls.
> Creating links to pages from within services seems like such a
> common paradigm (redirecting to the login page on authentication
> failure, for example); maybe we ought to have cleaner, public
> support for it...
I totally agree with Robert. Plus, what is the difference between:
componentSource
.getPage
(XXX.class).getComponentResources().createPageLink(XXX.class,true);
componentSource
.getPage
(YYY.class).getComponentResources().createPageLink(XXX.class,true);
Will I still get the same link? If so, why do I need to get a page in
first place?
/Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: 5.0.18 - 5.1.0.1 upgrade problems
Posted by Robert Zeigler <ro...@scazdl.org>.
I think that's ugly. :)
Consider:
componentSource
.getPage
(Index.class).getComponentResources().createPageLink(Index.class,true);
Personally, I get suspicious of call chains nested more than about two-
deep... smells of tight coupling.
Ultimately, componentResources.createPageLink calls into LinkSource,
which calls into ComponentEvenLinkEncoder to create the link. *shrug*.
Why not bypass the nastiness and go straight to
ComponentEventLinkEncoder? It /is/ a public service, after all...
Personally, though, I wonder if it should be the other way around:
ComponentEventLinkEncoder really exposes too much of the internal
"guts" of how tapestry "thinks" about requests: page names, nested
component ids, etc. (In the form of the PageRequestParameters and
ComponentEventRequestParameters objects. In that regard, using
component resources is "correct" because it "hides" all of the gory
details...
Except that it still requires an ugly rats' nest of method calls.
Creating links to pages from within services seems like such a common
paradigm (redirecting to the login page on authentication failure, for
example); maybe we ought to have cleaner, public support for it...
Robert
On Mar 23, 2009, at 3/2310:47 AM , Howard Lewis Ship wrote:
> The correct approach is to use ComponentSource
> (http://tapestry.formos.com/nightly/tapestry5/apidocs/org/apache/tapestry5/services/ComponentSource.html
> )
> to acquire a page.
>
> You can then get its ComponentResources and generate a page render
> Link from the resources.
>
> On Mon, Mar 23, 2009 at 8:36 AM, Massimo Lusetti
> <ml...@gmail.com> wrote:
>> On Mon, Mar 23, 2009 at 4:29 PM, Robert Zeigler
>> <ro...@scazdl.org> wrote:
>>
>>> If you want to stick with public services, and you're using 5.1,
>>> you can
>>> use:
>>> http://tapestry.formos.com/nightly/tapestry5/apidocs/org/apache/tapestry5/services/ComponentEventLinkEncoder.html
>>>
>>> I don't think it's quite as convenient to use as LinkSource, but
>>> at least
>>> it's public. :)
>>
>> I think that's the better bet we can have and that has been made for
>> similar use cases.
>>
>> --
>> Massimo
>> http://meridio.blogspot.com
>>
>> ---------------------------------------------------------------------
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: 5.0.18 - 5.1.0.1 upgrade problems
Posted by Howard Lewis Ship <hl...@gmail.com>.
The correct approach is to use ComponentSource
(http://tapestry.formos.com/nightly/tapestry5/apidocs/org/apache/tapestry5/services/ComponentSource.html)
to acquire a page.
You can then get its ComponentResources and generate a page render
Link from the resources.
On Mon, Mar 23, 2009 at 8:36 AM, Massimo Lusetti <ml...@gmail.com> wrote:
> On Mon, Mar 23, 2009 at 4:29 PM, Robert Zeigler <ro...@scazdl.org> wrote:
>
>> If you want to stick with public services, and you're using 5.1, you can
>> use:
>> http://tapestry.formos.com/nightly/tapestry5/apidocs/org/apache/tapestry5/services/ComponentEventLinkEncoder.html
>>
>> I don't think it's quite as convenient to use as LinkSource, but at least
>> it's public. :)
>
> I think that's the better bet we can have and that has been made for
> similar use cases.
>
> --
> Massimo
> http://meridio.blogspot.com
>
> ---------------------------------------------------------------------
> 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: 5.0.18 - 5.1.0.1 upgrade problems
Posted by Massimo Lusetti <ml...@gmail.com>.
On Mon, Mar 23, 2009 at 4:29 PM, Robert Zeigler <ro...@scazdl.org> wrote:
> If you want to stick with public services, and you're using 5.1, you can
> use:
> http://tapestry.formos.com/nightly/tapestry5/apidocs/org/apache/tapestry5/services/ComponentEventLinkEncoder.html
>
> I don't think it's quite as convenient to use as LinkSource, but at least
> it's public. :)
I think that's the better bet we can have and that has been made for
similar use cases.
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: 5.0.18 - 5.1.0.1 upgrade problems
Posted by Robert Zeigler <ro...@scazdl.org>.
If you want to stick with public services, and you're using 5.1, you
can use:
http://tapestry.formos.com/nightly/tapestry5/apidocs/org/apache/tapestry5/services/ComponentEventLinkEncoder.html
I don't think it's quite as convenient to use as LinkSource, but at
least it's public. :)
Robert
On Mar 23, 2009, at 3/236:04 AM , Ville Virtanen wrote:
>
> For the exact same reason we use:
>
> String pageName = someObject.getPageName();
> Class<?> pageClass = someObject.getPageClass();
> if (pageClass != null) {
> pageName =
> resolver.resolvePageClassNameToPageName(pageClass.getName());
> }
> pageLink = linkSource.createPageRenderLink(pageName, true, new
> Object[]{});
>
> where resolver is ComponentClassResolver and linkSource is LinkSource.
>
> Still, you have to use internal services atm :(
>
> - Ville
>
>
> Andreas Pardeike-2 wrote:
>>
>> On 21 mar 2009, at 18.19, Robert Zeigler wrote:
>>
>>> What's more is that it makes absolutely no sense to inject into a
>>> service;
>>> ComponentResource for which component, in particular?
>>
>> My Exception service has a method that handles my own redirect
>> execptions. Those
>> have an embedded parameter PageClassName which needs to be converted
>> to an url.
>>
>> Previously, I used ComponentResource for creating a page link from a
>> Page (which
>> I get from RequestPageCache). How do I do this with 5.1?
>>
>> /Andreas Pardeike
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/5.0.18---5.1.0.1-upgrade-problems-tp22619066p22657980.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: 5.0.18 - 5.1.0.1 upgrade problems
Posted by Ville Virtanen <vi...@cerion.fi>.
For the exact same reason we use:
String pageName = someObject.getPageName();
Class<?> pageClass = someObject.getPageClass();
if (pageClass != null) {
pageName = resolver.resolvePageClassNameToPageName(pageClass.getName());
}
pageLink = linkSource.createPageRenderLink(pageName, true, new Object[]{});
where resolver is ComponentClassResolver and linkSource is LinkSource.
Still, you have to use internal services atm :(
- Ville
Andreas Pardeike-2 wrote:
>
> On 21 mar 2009, at 18.19, Robert Zeigler wrote:
>
>> What's more is that it makes absolutely no sense to inject into a
>> service;
>> ComponentResource for which component, in particular?
>
> My Exception service has a method that handles my own redirect
> execptions. Those
> have an embedded parameter PageClassName which needs to be converted
> to an url.
>
> Previously, I used ComponentResource for creating a page link from a
> Page (which
> I get from RequestPageCache). How do I do this with 5.1?
>
> /Andreas Pardeike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/5.0.18---5.1.0.1-upgrade-problems-tp22619066p22657980.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: 5.0.18 - 5.1.0.1 upgrade problems
Posted by Andreas Pardeike <ap...@fsys.se>.
On 21 mar 2009, at 18.19, Robert Zeigler wrote:
> What's more is that it makes absolutely no sense to inject into a
> service;
> ComponentResource for which component, in particular?
My Exception service has a method that handles my own redirect
execptions. Those
have an embedded parameter PageClassName which needs to be converted
to an url.
Previously, I used ComponentResource for creating a page link from a
Page (which
I get from RequestPageCache). How do I do this with 5.1?
/Andreas Pardeike
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: 5.0.18 - 5.1.0.1 upgrade problems
Posted by Robert Zeigler <ro...@scazdl.org>.
This is already clear.
Stuff in org.apache.tapestry5.services,
org.apache.tapestry5.ioc.services, etc. can be injected. (For that
matter, org.apache.tapestry5.internal.services classes can be injected
as well, but that's not advised). Anything else can't be injected
into other services.
ComonentResources is in package org.apache.tapestry5. Clear /not/ a
service.
What's more is that it makes absolutely no sense to inject into a
service; ComponentResource for which component, in particular?
Robert
On Mar 21, 2009, at 3/216:05 AM , Ville Virtanen wrote:
>
> It would be great if the documentation (javadoc) for an example
> would state
> this clearly in every service interface documentation IF the service
> cannot
> be used in another service.
>
> Now you just need to know which services are "special".
>
> - Ville
>
>
> Thiago H. de Paula Figueiredo wrote:
>>
>> On Fri, Mar 20, 2009 at 10:53 AM, Andreas Pardeike <ap...@fsys.se>
>> wrote:
>>> Thiago,
>>
>> Hi!
>> Thinking further, ComponentResources is not a service, but something
>> that has special injection logic that only handles components, pages
>> and mixins. It is a way of a component, page or mixin to access all
>> the methods and properties Tapestry adds to them. Thus, I don't know
>> how to inject it in a service.
>>
>> You can file a JIRA asking for some way of doing that.
>>
>> --
>> Thiago
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/5.0.18---5.1.0.1-upgrade-problems-tp22619066p22634872.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: 5.0.18 - 5.1.0.1 upgrade problems
Posted by Ville Virtanen <vi...@cerion.fi>.
It would be great if the documentation (javadoc) for an example would state
this clearly in every service interface documentation IF the service cannot
be used in another service.
Now you just need to know which services are "special".
- Ville
Thiago H. de Paula Figueiredo wrote:
>
> On Fri, Mar 20, 2009 at 10:53 AM, Andreas Pardeike <ap...@fsys.se> wrote:
>> Thiago,
>
> Hi!
> Thinking further, ComponentResources is not a service, but something
> that has special injection logic that only handles components, pages
> and mixins. It is a way of a component, page or mixin to access all
> the methods and properties Tapestry adds to them. Thus, I don't know
> how to inject it in a service.
>
> You can file a JIRA asking for some way of doing that.
>
> --
> Thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/5.0.18---5.1.0.1-upgrade-problems-tp22619066p22634872.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: 5.0.18 - 5.1.0.1 upgrade problems
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Fri, Mar 20, 2009 at 10:53 AM, Andreas Pardeike <ap...@fsys.se> wrote:
> Thiago,
Hi!
Thinking further, ComponentResources is not a service, but something
that has special injection logic that only handles components, pages
and mixins. It is a way of a component, page or mixin to access all
the methods and properties Tapestry adds to them. Thus, I don't know
how to inject it in a service.
You can file a JIRA asking for some way of doing that.
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: 5.0.18 - 5.1.0.1 upgrade problems
Posted by Andreas Pardeike <ap...@fsys.se>.
Thiago,
I removed ComponentResources from the constructor and used a field
instead.
With
@InjectResource
private ComponentResources _componentResources;
I get
[ERROR] Registry Unable to determine resource value to inject into
field '_componentResources' (of type
org.apache.tapestry5.ComponentResources).
[ERROR] Registry Operations trace:
[ERROR] Registry [ 1] Realizing service ExceptionHandler
[ERROR] Registry [ 2] Invoking
se.fsys.klubb.core.handlers.ExceptionHandler(RequestPageCache,
PageResponseRenderer, Logger, Response, ComponentClassResolver,
boolean) (at ExceptionHandler.java:35) via
se.fsys.klubb.services.TweaksModule.bind(ServiceBinder) (at
TweaksModule.java:60)
[ERROR] Registry [ 3] Calculating injection value for field
'_componentResources' (org.apache.tapestry5.ComponentResources)
[ERROR] ExceptionHandler Construction of service ExceptionHandler
failed: Error invoking constructor
se.fsys.klubb.core.handlers.ExceptionHandler(RequestPageCache,
PageResponseRenderer, Logger, Response, ComponentClassResolver,
boolean) (at ExceptionHandler.java:35) via
se.fsys.klubb.services.TweaksModule.bind(ServiceBinder) (at
TweaksModule.java:60) (for service 'ExceptionHandler'): Unable to
determine resource value to inject into field
'_componentResources' (of type org.apache.tapestry5.ComponentResources).
and with
@Inject
private ComponentResources _componentResources;
I get
[ERROR] Registry No service implements the interface
org.apache.tapestry5.ComponentResources.
[ERROR] Registry Operations trace:
[ERROR] Registry [ 1] Realizing service ExceptionHandler
[ERROR] Registry [ 2] Invoking
se.fsys.klubb.core.handlers.ExceptionHandler(RequestPageCache,
PageResponseRenderer, Logger, Response, ComponentClassResolver,
boolean) (at ExceptionHandler.java:34) via
se.fsys.klubb.services.TweaksModule.bind(ServiceBinder) (at
TweaksModule.java:60)
[ERROR] Registry [ 3] Calculating injection value for field
'_componentResources' (org.apache.tapestry5.ComponentResources)
[ERROR] Registry [ 4] Resolving object of type
org.apache.tapestry5.ComponentResources using MasterObjectProvider
[ERROR] ExceptionHandler Construction of service ExceptionHandler
failed: Error invoking constructor
se.fsys.klubb.core.handlers.ExceptionHandler(RequestPageCache,
PageResponseRenderer, Logger, Response, ComponentClassResolver,
boolean) (at ExceptionHandler.java:34) via
se.fsys.klubb.services.TweaksModule.bind(ServiceBinder) (at
TweaksModule.java:60) (for service 'ExceptionHandler'): No service
implements the interface org.apache.tapestry5.ComponentResources.
BTW, my exception handler is registered with:
public static void
contributeAliasOverrides(@InjectService("ExceptionHandler")
RequestExceptionHandler myHandler, @Inject
@Symbol(SymbolConstants.PRODUCTION_MODE) boolean productionMode,
Configuration<AliasContribution<RequestExceptionHandler>>
configuration) {
configuration
.add(AliasContribution.create(RequestExceptionHandler.class,
myHandler));
}
and the class/constructor (that worked fine in 5.0.18) looks like this:
public class ExceptionHandler implements RequestExceptionHandler
{
@InjectResource
private ComponentResources _componentResources;
private final RequestPageCache _pageCache;
private final PageResponseRenderer _renderer;
private final Logger _logger;
private final Response _response;
private final ComponentClassResolver _resolver;
private final boolean _productionMode;
public ExceptionHandler(RequestPageCache pageCache,
PageResponseRenderer renderer, final Logger logger, final Response
response, final ComponentClassResolver resolver, @Inject
@Symbol(SymbolConstants.PRODUCTION_MODE) boolean productionMode)
{
_pageCache = pageCache;
_renderer = renderer;
_logger = logger;
_response = response;
_resolver = resolver;
_productionMode = productionMode;
}
...
}
/Andreas
On 20 mar 2009, at 14.12, Thiago H. de Paula Figueiredo wrote:
> On Fri, Mar 20, 2009 at 9:54 AM, Andreas Pardeike <ap...@fsys.se> wrote:
>> Thiago,
>
> Hi!
>
>> I don't think that will help. ExceptionHandler is a service
>
> Oops, I overlooked that . . .
>
>> and I am not sure if I can use field injection in a service
>> (everything should be done in the
>> constructor, right?).
>
> Yes we can! :)
>
>> If I try to do it your way, I end up with Eclipse
>> complaining that that field isn't initialized...
>
> I guess this wouldn't happen if you don't mark the field as final.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: 5.0.18 - 5.1.0.1 upgrade problems
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Fri, Mar 20, 2009 at 9:54 AM, Andreas Pardeike <ap...@fsys.se> wrote:
> Thiago,
Hi!
> I don't think that will help. ExceptionHandler is a service
Oops, I overlooked that . . .
> and I am not sure if I can use field injection in a service (everything should be done in the
> constructor, right?).
Yes we can! :)
> If I try to do it your way, I end up with Eclipse
> complaining that that field isn't initialized...
I guess this wouldn't happen if you don't mark the field as final.
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: 5.0.18 - 5.1.0.1 upgrade problems
Posted by Andreas Pardeike <ap...@fsys.se>.
Thiago,
I don't think that will help. ExceptionHandler is a service and I am
not sure
if I can use field injection in a service (everything should be done
in the
constructor, right?). If I try to do it your way, I end up with Eclipse
complaining that that field isn't initialized...
On 20 mar 2009, at 13.11, Thiago H. de Paula Figueiredo wrote:
> On Fri, Mar 20, 2009 at 9:08 AM, Andreas Pardeike <ap...@fsys.se> wrote:
>
>> 2) ComponentResources
>> ---------------------
>>
>> public class ExceptionHandler implements RequestExceptionHandler
>> {
>> public ExceptionHandler(RequestPageCache pageCache,
>> PageResponseRenderer
>> renderer, final Logger logger, final Response response, final
>> ComponentClassResolver resolver, final ComponentResources
>> componentResources, @Inject
>> @Symbol(SymbolConstants.PRODUCTION_MODE) boolean
>> productionMode)
>> {
>> }
>> }
>
> Use field injection for ComponentResources instead of using the
> constructor. ComponentResources is not a service, so I don't know how
> this worked before.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: 5.0.18 - 5.1.0.1 upgrade problems
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Fri, Mar 20, 2009 at 9:08 AM, Andreas Pardeike <ap...@fsys.se> wrote:
> 2) ComponentResources
> ---------------------
>
> public class ExceptionHandler implements RequestExceptionHandler
> {
> public ExceptionHandler(RequestPageCache pageCache, PageResponseRenderer
> renderer, final Logger logger, final Response response, final
> ComponentClassResolver resolver, final ComponentResources
> componentResources, @Inject @Symbol(SymbolConstants.PRODUCTION_MODE) boolean
> productionMode)
> {
> }
> }
Use field injection for ComponentResources instead of using the
constructor. ComponentResources is not a service, so I don't know how
this worked before.
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org