[
http://www.stripesframework.org/jira/browse/STS-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11901#action_11901
]
Aleksander Zarczynski commented on STS-747:
-------------------------------------------
Thanks for such quick answer :-)
Exactly - in my case Stripes are loaded by shared class loader. I'm not sure if
you know Tomcat's class loader hierarchy? In general shared libraries are
loaded by class loader which is common to all of the applications deployed on
the same server, and each application has its own (additional) class loader,
which loads entire stuff bundled inside a war archive.
We use Stripes as shared library intentionally. We don't want to have multiple
copies of the library (inside each of the applications). In addition, we have
some common libraries which also depend on Stripes, and are loaded by the
shared class loader. This forces us to use Stripes also as a shared library.
Could you please explain why using Stripes as a shared library (the same class
loader) is not recommended? And maybe you already have any solution for such
kind of problems?
> ActionBean names from different applications conflict with each other.
> ----------------------------------------------------------------------
>
> Key: STS-747
> URL: http://www.stripesframework.org/jira/browse/STS-747
> Project: Stripes
> Issue Type: Bug
> Components: ActionBean Dispatching
> Affects Versions: Release 1.5.3
> Environment: Tomcat 5.5, Stripes deployed as shared library.
> Reporter: Aleksander Zarczynski
>
> I have two applications deployed on the Tomcat server, with Stripes deployed
> as a shared library. Both contain ActionBeans with the same names. The name
> patterns are following:
> net.company.app1.action.SomeActionBean
> net.company.app2.action.SomeActionBean
> The applications are deployed in different contexts: app1 and app2. So, the
> beans are accessible under following urls (relative to server root):
> /app1/Some.action
> /app2/Some.action
> The problem is that only one of the ActionBeans are accessible at the same
> time. If app2 is deployed latter, its ActionBean is resolved correctly, but
> any request to /app1/Some.action is resolved also to /app2/Some.action.
> Analogical problem occurs when app1 is deployed after app2.
> I found following comment in the UrlBindingFactory.addBinding() method:
> "Search for a class that has already been added with the same name as the
> class being added now. If one is found then remove its information first and
> then proceed with adding it. I know this is not technically correct because
> two classes from two different class loaders can have the same name, but this
> feature is valuable for extensions that reload classes and I consider it
> highly unlikely to be a problem in practice."
> I'm not familiar with the code enough to be sure that this design decision is
> a reason of the problem (however, the Tomcat uses different class loader for
> each application). But if so, it's also quite big limitation imposed on
> applications internal architecture. Maybe the context path could be also
> taken into account in internal structures of the dispatcher?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://www.stripesframework.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
