[ 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
