[jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-3660) Add option to move Seam imported namespaces into a CompositeNamespace

[Michael Youngstrom (JIRA)]

     [ https://jira.jboss.org/jira/browse/JBSEAM-3660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Youngstrom updated JBSEAM-3660:
---------------------------------------

    Fix Version/s: The future
                       (was: 2.1.1.CR1)


I'm having trouble justifying this feature.  It really only helps apps that don't use Seam as their primary framework which is quite rare currently.  I'll keep this issue in the tracker for future reference as one possible way to improve SeamELResolver Performance.

> Add option to move Seam imported namespaces into a CompositeNamespace
> ---------------------------------------------------------------------
>
>                 Key: JBSEAM-3660
>                 URL: https://jira.jboss.org/jira/browse/JBSEAM-3660
>             Project: Seam
>          Issue Type: Feature Request
>          Components: EL
>    Affects Versions: 2.0.3.CR1
>            Reporter: Michael Youngstrom
>            Assignee: Michael Youngstrom
>             Fix For: The future
>
>
> In some profiling I've done recently SeamELResolver is a major hot spot.  In the current SeamELResolver code the resolver currently checks the root namespace to resolve the property.  If it is not found there then the SeamELResolver will check all of the imported namespaces to see if the value can be resolved by prepending the namespace.  In Seam 2.0.3 this results in 14 calls to Contexts.lookupInStatefulContexts() which is a rather expensive operation since it asks each one of the 8 scopes for the value.  Often times each check involves several string appends and several hashmap lookups.
> If most of the el requests are user defined seam components this is not much of a problem.  However, frequently this is not the case.  For example, In an h:dataTable every time the "var" value is requested in an expresion it will have to go through all 14 Contexts.lookupInStatefulContexts() every time since it will not find the dataTable var in any of the seam scopes.
> Same thing for the s:selectItems component.  A great component but it makes 5 or so EL requests for each option in the list which can begin to add up quickly.  Another case is people who are using Spring (my problem) :).
> I think it would be a good idea to add an option to make SeamELResolver a better citizen in the ELResolver chain.  One way to do this is to add an option to core:init that would move all Seam imported namespaces into a single child namespace.  the option could look like this:
> <init:core core-imported-prefix="seam"/>
> This would be completely optional.  It would move all namespaces that begin with "org.jboss.seam" into a seam composite namespace.  The only impact it would have is that the developer would need to prefix the standard component with "seam." like #{seam.locale}.  There are not a lot of standard seam components that are frequently accessed through EL. #{seam.messages} comes to mind.  But for projects that need it this would make SeamELResolver resolution 93% faster.  This wouldn't create any backwards compatibility problems because it would be completely optional.  But at the same time projects that need to take advantage of it can.
> I can prepare a patch for this if the idea is approved.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira