[
http://www.stripesframework.org/jira/browse/STS-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11913#action_11913
]
Nikolaos commented on STS-747:
------------------------------
I agree with Ben on the "Won't Fix" designation of this issue and just wanted
to add that although shared libraries mean one less thing to have a copy of /
version and maintain in each web project it creates a pile of issues just like
this one... in the MS Windows world this was referred to as "DLL Hell"... and
anyone who has built a Windoze app with DLL dependencies can speak volumes to
the fun that arises with shared libraries and things being there OR simply not
OR the wrong versions being there!
IMO the shared libraries of a web container should be STRICTLY limited to
things that absolutely NEED to be there and the only thing I can think of is
something the web container itself requires but even then I haven't found a
reason to do so ever with Java in my personal experience. There is some
implicit beauty in the fact that a WAR can contain everything a web application
needs and IMO that is were the web apps libraries should be bundled.
Now your REAL issue appears to be one of "dependency versioning". That problem
has been solved. Take a look at Maven 2 especially if you have multiple
projects. The learning curve is steep but once you reap its benefits / rewards
I'm sure you won't be sorry.
> 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
