[
http://www.stripesframework.org/jira/browse/STS-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11975#action_11975
]
Aleksander Zarczynski commented on STS-747:
-------------------------------------------
Nikolaos,
Your remarks are very convincing. Unfortunately, in our system we have few
legacy "system wide" singletons, which can't be refactored at the moment (it's
rather "political" than technical limitation). But I agree that the separate
services layer is much better solution. Thanks again for your answers :-)
> 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
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
