Menu
▾
▴
Re: [Springframework-developer] Removing cyclic dependencies in sub-packages
|
From: <jue...@we...> - 2004-03-29 12:55:18
|
As a side note, the refined semantics of = TransactionSynchronization.beforeCompletion (part of the Hibernate/JTA = synchronization bugfix) for 1.0.1 are probably a more noteworthy = incompatibility than the AopUtils move. It's still negligible, as hardly = anyone will implement custom TransactionSynchronizations, particularly = not with both beforeCommit and beforeCompletion implementations... but = strictly speaking, it's an incompatibility too. I'm for a pragmatic approach here: If something is marked "for internal = use" (like the whole aop.framework.support package), we can apply = changes for point releases, as long as there's a straightforward upgrade = path for those people that do use those classes directly (if any). Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of j=FCrgen h=F6ller [werk3AT] Sent: Monday, March 29, 2004 2:35 PM To: spr...@li... Subject: [Springframework-developer] Removing cyclic dependencies in sub-packages On the occasion of a hint in our current TSS thread, I've run a cyclic = dependency analysis on our current codebase, using JDepend. There are two minor cycles in the AOP framework: - The main one affects AopConfigException, which resides in = aop.framework but is used in the aop.IntroductionAdvisor interface and = DefaultIntroductionAdvisor implementation, for the validateInterfaces = method. I've simply used IllegalArgumentException there, which is = consistent with other initialization checks within Spring; this has = removed the AopConfigException cycle. - The other one affects AopUtils, which resides in aop.framework.support = but is used outside aop.framework, causing a cyclic dependency. As = AopUtils is clearly an internal class, not for direct use by = applications, I've moved it to aop.support; this removes the AopUtils = cycle too. The only remaining cycle is DispatcherServlet's instantiation of a = default ViewResolver, default HandlerMapping, etc: This causes a cycle = between web.servlet and web.servlet.view/i18n/etc. However, I consider = this acceptable, as it is just about fallback defaults. We could remove = this by referring to the default implementation classes by name, but = that feels odd. Strictly speaking, the AopUtils move is not backward-compatible, but I'm = not keen on keeping a deprecated class in the old place. As we're = talking about an internal class here, I guess this won't break any = existing application. This raises the following issue: What exactly = constitutes our public API? We will occasionally face the need to revise = internals, even for point releases... Thoughts? Objections? Juergen DI J=FCrgen H=F6ller Senior System Architect ______________________________________ werk3ATS - division systementwicklung werk3AT informations- und mediensysteme europaplatz 4 A - 4020 linz t. +43 (0) 732 71 65 29 502 f. +43 (0) 732 71 65 29 3 mailto:jue...@we... http://www.werk3at.com ______________________________________ werk3ATS - WIR ENTWICKELN ERFOLG ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
