-
1. Re: What are the aslias defined for the built in seam compon
This probably needs better documentation, but when you ask for a "foo" component, Seam first looks for "foo" and then it looks for "foo" in any imported namespaces. Note that components can have @Import declarations, and I believe that we have an open issue for imports in a *.page.xml file too. (Not sure if that is in now or not)
Seam does not use the factory tag internally anymore.
I've opened http://jira.jboss.com/jira/browse/JBSEAM-2563 so we can get the docs updated. -
2. Re: What are the aslias defined for the built in seam compon
Thank you for the quick reply.
So if I understand you right, with an import statement like
org.jboss.seam.core
org.jboss.seam.transaction
in the seam.jar components.xml file, when I use #{contexts}, seam will:
1. try to find the "contexts" component in all the available contexts
2. if failed, seam will try to find the "org.jboss.seam.core.contexts" component instead
3. if failed again, seam will try to find the "org.jboss.seam.transaction.contexts" component
4. repeat step 3 till seam finds a matching component or all imports are tried
If true, this wouldn't be very efficient, would it? -
3. Re: What are the aslias defined for the built in seam compon
Yes, that's pretty much what it does. Yes, it's not exactly efficient, but I'm not sure I know another way to do it that preserves correctness.
-
4. Re: What are the aslias defined for the built in seam compon
Thanks for the clarification, really appreciate it.
I don't have the required insight knowledge in order to provide a good solution. One suggestion I have would be: it seems that the components need to registered with seam first in order to be used. Theoretically, a map from the component's names to the component can be built for fast look up whenever a component is referenced. I do think this worth given the extra care as component references are everywhere in a Seam application. -
5. Re: What are the aslias defined for the built in seam compon
In general it is sensible to analyze the bottlenecks and performance blackspots rather than spend hours rewriting bits of code which may in fact be very performant compared to others.
It sounds like you are interested in this - perhaps you could contribute a better solution (that preserves correctness as Norman says).
We are doing some performance/scalability analysis currently. -
6. Re: What are the aslias defined for the built in seam compon
I haven't benchmarked this, but the lookups are basically a series of hashtable lookups, which makes it a pretty speedy thing altogether.
On the issue of creating a name index for components, the problem I see is that the underlying contexts are very dynamic. The meaning of "foo" could easily change out from underneath us. (if there weren't the potential for conflict, we wouldn't need namespaces in the first place) I can't see any way that the required indexing (even if it were possible for all contexts) wouldn't be a much more expensive operation.
I think the best solution is that if performance is a concern, always use the fully qualified name or create aliases. In the core seam code we always use the fully qualified name. Failing that, @Import and your own custom factory values could be used to optimize lookups for anything you observe to be a performance problem. So far, of all the inefficient things Seam is doing, this is fairly low down the list of things that are likely to have an impact on overall performance.
That being said, we love to see profiling results on real applications. We are 100% committed to making sure Seam isn't slowing your application down. -
7. Re: What are the aslias defined for the built in seam compon
Well said. I agree that if it's just a series of hash table lookup, it is unlikely to surface as a performance problem. I also agree on the concern with indexing, given the dynamic nature of the seam contexts.
Toward the end of my current project, I might need to do some profiling and will post it here if I am able to identify any bottleneck.
Sometimes, the performance might be from the other libraries used in a seam app. Such as one I experienced when a page takes > 8 seconds to load with a selection that has 800 items in it, it's from the JSF implementation rather than seam.