Menu
▾
▴
springframework-developer
|
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 |
|
From: <rod...@in...> - 2004-03-29 13:00:52
|
>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... I'm happy with this move. The only legitimate reason people might use it is to check whether a particular instance is an AOP proxy in a test case (rather than application code). I think we should publish a list of the public API contracts that won't change. With the AOP stuff, I've made some of the classes package-visible, but that's often impossible. Axis did this way back and I thought it was a good idea. Regards, Rod |
|
From: <jue...@we...> - 2004-03-29 13:13:20
|
This could be as simple as collecting the public API in a readme: = Package names for entirely public packages, individual class names for = more specific cases. This should not be too hard to do. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of rod...@in... Sent: Monday, March 29, 2004 3:01 PM To: spr...@li... Subject: Re: [Springframework-developer] Removing cyclic dependencies in sub-packages >Strictly speaking, the AopUtils move is not backward- compatible, but I'm not keen on keeping a deprecated class in=20 the old place. As we're talking about an internal class here,=20 I guess this won't break any existing application. This=20 raises the following issue: What exactly constitutes our=20 public API? We will occasionally face the need to revise=20 internals, even for point releases... I'm happy with this move. The only legitimate reason people=20 might use it is to check whether a particular instance is an=20 AOP proxy in a test case (rather than application code). I think we should publish a list of the public API contracts=20 that won't change. With the AOP stuff, I've made some of the=20 classes package-visible, but that's often impossible. Axis did this way back and I thought it was a good idea.=20 Regards, Rod ------------------------------------------------------- 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=3D1470&alloc_id=3D3638&op=3Dcli= ck _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
