[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cactus-dev
Subject:    RE: svn commit: r292559 - in
From:       Kenney Westerhof <forge () neonics ! com>
Date:       2005-09-30 10:51:38
Message-ID: Pine.LNX.4.58.0509301240050.6044 () fire ! homenet ! neonics ! com
[Download RAW message or body]

On Fri, 30 Sep 2005, Vincent Massol wrote:

Hi Vincent e.a.,

> Hi Kenney and all,
> > Decoupled share-12-13-14 from Wrapper implementations using reflection
> > (a newInstance method in the AbstractXXXWrapper).
> >
> > Updated Wrapper-implementation references to use the Abstract base class.
>
> Does this break the Cactus public API? If so, we need to decide what to do
> about it as Cactus has been stable for a long time and users may not
> understand why we break it without any added advantage for them. Also, we
> could name it Cactus 2.x but maybe it's hard to justify as there is no new
> feature? I'm open to all suggestions but we need to all agree as this is an
> important change it seems (unless I'm reading this wrong).

There are two or three instances where the public api has changed,
for instance:

cactus-framework-share-13-14/src/main/java/org/apache/cactus/FilterTestCase.java
:
-    public org.apache.cactus.server.HttpServletRequestWrapper request;
+    public AbstractHttpServletRequestWrapper request;

I'm not entirely sure wheter this'll break existing binaries, since the
types are assignable, but I know that existing classes might mark
that field as being the subtype instead of the supertype. It might work,
it might not.

What I know for sure is that when you recompile any sources that use those
public fields, they recompile without error.

Another change is that I added public static XXX newInstance(constructor
params) methods to some AbstractXXWrappers. A new method shouldn't break
existing code, but might also need recompilation.

The final change is non-breaking in that some code uses the newInstance
method and not the 'new' call, but that's invisible to users.

I don't think a 2.x version is warranted here, because there are no new
features, as you said.

I do think that when you guys release version 18 (or later), and these
changes are in, that it's reasonable to expect people to recompile
their sources against the new cactus version, in which case there
shouldn't be any problems.

I've thought long and hard about changing those public methods, and this
was the cleanest solution to decouple the projects (and remove circular
dependencies). The other solution involved changing the Wrapper classes
to be interfaces and renaming the implementation classes.

But if this is a problem I'm sure I can think of another solution
which probably involves duplicating code.

-- Kenney


---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]