-
15. Re: Seam performance problem + rewarding workaround...
cerdiogenes Aug 6, 2008 2:03 AM (in response to toby.tobias.hill.gmail.com)Could you say me how I configure the filter? I read http://java.sun.com/products/servlet/Filters.html but don't realize how I must configure it.
Thanks.
-
16. Re: Seam performance problem + rewarding workaround...
cerdiogenes Aug 6, 2008 8:59 PM (in response to toby.tobias.hill.gmail.com)I realized how to configure it.
<filter> <filter-name>Timing Filter</filter-name> <filter-class>br.unioeste.sadau.TimingFilter</filter-class> </filter> <filter-mapping> <filter-name>Timing Filter</filter-name> <url-pattern>/admin/*</url-pattern> </filter-mapping>
Thanks for these tips Tobias! Very appreciated.
Carlos.
-
17. Re: Seam performance problem + rewarding workaround...
toby.tobias.hill.gmail.com Aug 6, 2008 9:23 PM (in response to toby.tobias.hill.gmail.com)Hi Carlos,
Actually your way is the standard Servlet way of defining a filter. It works but mounts the filter outside all filters in Seam ... sometimes not what you want.
You could as well (or even better I would say) let Seam handle this for you. Just annotate your filter like this:
@Scope(ScopeType.APPLICATION) @Name("timingFilter") @BypassInterceptors @Install(value = false, precedence = Install.APPLICATION) @Filter public class TimingFilter extends AbstractFilter { . . . }
Note that what we say above is that we don't want to install the filter by default (@Install(value=false ... )). This gives you the opportunity to instead define in components.xml whether you want the filter on or off for this particular config. For instance I have this filter turned on locally, in dev- and in test-environments, but not on stage or in prod.
For instance my local version of components.xml looks like this:
<component class="se.reco.web.filter.TimingFilter"> <property name="regexUrlPattern">(^/.*.seam)|(^/[0-9a-zA-ZåäöÅÄÖ\-/]+$)</property> <property name="disabled">false</property> <property name="output">SCREEN</property> </component>
See more examples of how @Filter is being used in some of the example applications provided with Seam.
-
18. Re: Seam performance problem + rewarding workaround...
svetzal Aug 21, 2008 2:11 PM (in response to toby.tobias.hill.gmail.com)Tobias, this is awesome. Thank you for the details on your timing interceptor, mine is very simplistic as I wasn't sure a good way to start timing calls up the chain.
I may have been misplacing some of my criticism into JSF assuming it was component construction and reconstruction causing some performance problems that are still plaguing us on complex pages, but these are truly pages with large loops with complex structures underneath digging into bean data.
Time to dig back in for a quick code audit.
Thank you for posting this!
-
19. Re: Seam performance problem + rewarding workaround...
adamw Sep 8, 2008 12:33 PM (in response to toby.tobias.hill.gmail.com)Hello,
for the case when I've got a constant bean-dependent expression that should be displayed in a loop, I wrote a simple
let
tag, which, as opposed to c:set, evaluates the expression given, instead of serving as an alias, see here:Value-to-variable binding let tag
For any non-constant expressions creating a
data transfer
bean is still necessary, but may be quite tedious, so this often helps.Adam
-
20. Re: Seam performance problem + rewarding workaround...
danielc.roth Sep 9, 2008 11:00 AM (in response to toby.tobias.hill.gmail.com)Adam:
This is really quite cool. I don't know if there is any similar way to achieve this with the seam taglib (or with facelets). If not, I think it should be included. Pete?
-
21. Re: Seam performance problem + rewarding workaround...
pmuir Sep 17, 2008 11:22 AM (in response to toby.tobias.hill.gmail.com)The problem is that it alters the semantics of EL somewhat. Can you file a JIRA issue, and see how many votes it collects?
-
23. Re: Seam performance problem + rewarding workaround...
adamw Sep 18, 2008 6:13 PM (in response to toby.tobias.hill.gmail.com)
Pete Muir wrote on Sep 17, 2008 11:22:
The problem is that it alters the semantics of EL somewhat. Can you file a JIRA issue, and see how many votes it collects?How does it alter the semantics of EL? The implementation is really straightforward :).
--
Adam -
24. Re: Seam performance problem + rewarding workaround...
pmuir Sep 20, 2008 6:54 PM (in response to toby.tobias.hill.gmail.com)EL is designed around the idea of late evaluation, and so you don't need to worry about inadventently extending the life of an object beyond its intended scope. Can you post a link to the source?
-
25. Re: Seam performance problem + rewarding workaround...
adamw Sep 21, 2008 12:20 PM (in response to toby.tobias.hill.gmail.com)Hello,
the sources are in my private repo, but here's a package of them:
linkThe let-tag states explicitly that it uses eager. instead of lazy evaluation.
Also, I guess it would be possible to write a proxy which evaluates the value binding the first time it is accesed and stores it for later usage.btw.: I think e-mail notifications don't work :). I have the preference checked in my preferences, but I don't get any notifications.
Adam
-
26. Re: Seam performance problem + rewarding workaround...
adamw Sep 21, 2008 12:22 PM (in response to toby.tobias.hill.gmail.com)I guess lack of
http
confused the wiki software and turned it to afile not found
link. Here's the link again: link, and in text format just in case: http://www.warski.org/let-tag-sources.tar.gzAdam
-
27. Re: Seam performance problem + rewarding workaround...
pmuir Sep 21, 2008 9:46 PM (in response to toby.tobias.hill.gmail.com)Yup, but people often don't read the docs. I suggest you host it as an external project for now - lets see how it gets on...
You only get email notifications if you are the topic author :(
-
28. Re: Seam performance problem + rewarding workaround...
gus888 Oct 3, 2008 5:39 PM (in response to toby.tobias.hill.gmail.com)
Siarhei Dudzin wrote on Mar 11, 2008 20:10:
Just FYI: http://jira.jboss.com/jira/browse/JBSEAM-2704This is a great post, thanks a lot to Tobias. We ever tested Seam on our existing ICEfaces project, and found that its speed apparently slowed down. Now, we found the reason. Our beans have a lot of binding properties, which consume main call-times. Using outject/inject is option, but it is hard to outject/inject all properties, especially for the frame EntityHome's getInstance. For now, we are looking forward to seeing JBSEAM-2704 to be fixed. Thanks a lot to Seam Team in advance!
-
29. Re: Seam performance problem + rewarding workaround...
deanhiller2000 Jul 29, 2010 11:06 AM (in response to toby.tobias.hill.gmail.com)great post. If you do load testing at all, to not have one client reporting another client's method calls, you probably want to do a ThreadLocal, right?
public final static ThreadLocal<CallChain> callChain = new ThreadLocal<CallChain>(); static { callChain.set(new CallChain()); }