[
http://www.stripesframework.org/jira/browse/STS-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11973#action_11973
]
Aleksander Zarczynski commented on STS-747:
-------------------------------------------
Thank you for interesting remarks. However, you wrote that you hadn't found a
reason for having common libraries in your personal experience. I have (maybe
because my project is quite unusual). We have a lot of simple applications,
which use the same database, and few common tables. So, for example, the
hibernate is used as common library (to utilize common cache for all of the
applications). There are also few singletons which are used by the
applications, which makes them "system wide" singletons. And to achieve that
they have to be put in a shared library. Do you think that shared libraries
could be avoided in such a case?
Anyway, we managed to use separate copy of the Stripes per application, so it's
not a problem anymore.
> 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
