You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Mind Bridge (JIRA)" <ta...@jakarta.apache.org> on 2005/10/23 19:40:10 UTC
[jira] Resolved: (TAPESTRY-702) Use of statics in contrib:Table causes problems for multiple WARs in an EAR
[ http://issues.apache.org/jira/browse/TAPESTRY-702?page=all ]
Mind Bridge resolved TAPESTRY-702:
----------------------------------
Fix Version: 4.0
Resolution: Fixed
Assign To: Mind Bridge
Fixed.
The ultimate crime here was using caching for static variables.
The caching has been removed as there is context-specific caching in the page source
anyway.
In general the whole code should be refactored and should use the tools provided by HiveMind, but that is for the next version.
> Use of statics in contrib:Table causes problems for multiple WARs in an EAR
> ---------------------------------------------------------------------------
>
> Key: TAPESTRY-702
> URL: http://issues.apache.org/jira/browse/TAPESTRY-702
> Project: Tapestry
> Type: Bug
> Components: Contrib
> Versions: 3.0.3
> Environment: XP/Websphere (with Tapestry & Contrib jars at application/ear classloader level, shared between >1 war)
> Reporter: Aaron Dixon
> Assignee: Mind Bridge
> Fix For: 4.0
>
> The static finals in org.apache.tapestry.contrib.table.model.simple.SimpleTableColumn are inconsiderate of specific components that wish to share/reuse particular class implementations in the contrib library.
> Specifically our problem involved org.apache.tapestry.contrib.table.model.simple.SimpleTableColumn.FORM_COLUMN_RENDERER_SOURCE (which is of type SimpleTableColumnFormRendererSource).
> We have two different table components (being used in two different WARs that share Tapestry at the application classloader level within a single EAR). These components share the class implementors in org.apache.tapestry.contrib.* If we visit a page containing the first of our table components, the execution path through the contrib code causes FORM_COLUMN_RENDERER_SOURCE#getRenderer() to be called. This method lazy initializes one of its data members (m_objComponentRenderer), which is instantiated with reference to a particular namespace (which ultimately is pulled from the name space of whatever component is being used for the TableView). When we try to load our table component in a different namespace (after having already visiting a page with the first component), a similar execution path is taken that causes the FORM_COLUMN_RENDEER_SOURCE#getRenderer() method to be called again. However this time, because of the lazy initialization logic, the data member that was previously set/cached is used, but it is invalid for the current context (specifically, the namespace was no longer valid.)
> Granted we are doing something rather atypical here (by extending the Table component twice in a different namespace), but the use of statics here seem sketchy and once we fixed the problem in the tapestry source (simply by removing the lazy initialization for now), the problem went away, and our contrib table extensions worked as expected.
> I assume that there are other similar issues in contrib (relating to "static caching" like this).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org