hi simon
we all agree that the long term solution is to use an ArrayStack packaged as part of digester. in fact, if we new then what we know now about developing libraries, we have done this from the start.
i also agree that it's a trick and a hack but in my mind, it's the least worst solution.
ArrayStack is stable and mature. there have been no code changes (that i can see) in the last 18 months (http://cvs.apache.org/viewcvs.cgi/jakarta-commons/collections/src/ java/org/apache/commons/collections/ArrayStack.java) and there seem to be no substantial ones since the code was donated from Digester. this means that it's very, very unlikely that version problems will occur.
even setting aside the issue of containers (and the risks of insoluble binary compatibility issues), shipping a binary incompatible version of digester would cause compatibility problems for struts users (and anyone else using a framework dependent on digester). they would not be able to drop the new digester jar in as a replacement for the struts digester dependency. yes, they could recompile the struts release from source but i'm keen to see the new enhancements used as widely as possible. this means binary compatibility.
- robert
On 26 Jul 2004, at 04:45, Simon Kitching wrote:
On Mon, 2004-07-26 at 15:23, Craig McClanahan wrote:
For me, the most important decision is whether to roll back Craig
McClanahan's changes to the ArrayStack class. Craig added a copy of
ArrayStack as o.a.c.d.ArrayStack, to remove the dependency on
commons-collections. But this creates a binary compatibility; because
the field is protected, any existing code that subclasses Digester will
break.
Ah ... that's the rationale that I hadn't caught in the earlier thread ... and it makes perfect sense. The problem was that the package name was changed when I did the import, and that's the wrong thing to do. Robert did it right when he copied o.a.c.c.ArrayStack into beanutils ... the package name is still "collections".
If containers exist which expose the Digester to the containees, then we
probably do need to roll back this change. But I'm not convinced this is
the case.
The other significant issue is whether to require the new BeanUtils release for Digester.
I'm currently +1 on leaving Craig's changes in (-0 on removing them) +1 on requiring the latest BeanUtils.
If we pull this change back out, and go back to org.apache.commons.collections.ArrayStack, then the new Digester should work with either (a) old BeanUtils and old Collections, or (b) new BeanUtils
So, I'm currently: +1 on pulling this change out +1 on requiring new BeanUtils (and removing the explicit Collections dependency).
If someone wants to test the old-beanutils+collections scenario, we can document that combination as working as well.
But this concept of bundling o.a.c.collections classes with an o.a.c.digester distribution isn't stable long-term, right? It is only a short-term hack to preserve backwards compatibility for a short while until a better solution is implemented. It creates *really* nasty problems if an app ever wants to use a release of o.a.c.collections which has a modified ArrayStack class. And it's just not elegant.
The situation with BeanUtils is slightly different, due to the public
API which references collections; but even then, its not so different. A
protected field is part of the published API to a class too.
I believe the better (long-term) solution is to create
o.a.c.d.ArrayStack, just as Craig has done. Digester can then be used
without collections, and any version of collections can then be safely
used in the same classloader as Digester if someone desires it.
BeanUtils will then effectively do the same, resulting in a small amount
of code duplication, but with each app's dependencies being much
cleaner.
What exactly is this ugly hack of bundling o.a.c.c.ArrayStack with o.a.c.beanutils giving us? What is the plan for phasing out o.a.c.c.ArrayStack in favour of o.a.c.d.ArrayStack?
I can't currently see any real benefit in delaying implementing the proper solution. Yes, the change to o.a.c.d.ArrayStack is binary-incompatible. But as I said earlier, this is not a *bugfix* release (third-digit version change), but a *feature* release (second-digit version change), except for a fix to NodeCreateRule. No-one *has* to upgrade to the latest digester release. If someone chooses to upgrade, then they should recompile against the latest release, and then the problem goes away.
The container/containee relationship is the only case I can see where it
is not feasable to recompile against the new release; the distributor of
the container can't recompile the containees, and in many cases neither
can the sysop deploying the container. But as we've established, sane
containers don't expose their use of Digester to the containees, so that
argument is not valid.
Regards,
Simon
Regards,
Simon
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
