Introducing that non-backwards compatible change was painful,but (in
the long run) not as painful as having a ServiceImplementationFactory2
kind of interface!
I know its awkward, but perhaps you could have two implementations of
your service; the 1.1 impl and a backwards compatibility impl.
Use a HiveMind symbol to control which one is is instantiated:
<invoke-factory>
<construct class="${hivetrans.foo-service-impl-class}" ....
Then if you want compatibility with 1.0, provide an
ApplicationDefault for hivetrans.foo-service-impl-class that overrides
the default (which would be the 1.1 implementation).
On Fri, 7 Jan 2005 20:12:45 +0700, Jean-Francois Poilpret
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> I did not check out the latest HM1.1 yet (I am still working on the
> "official" release exclusively), but I know there are already some
> incompatibilities for libraries developed with HM1.0. In particular, in the
> case of HiveTranse, I have developed several ServiceImplementationFactory
> classes, and I read on the web that they will have to be rewritten for use
> with 1.1.
> I don't mind much about rewriting some classes for HM1.1, but I would like
> however to be able to deliver libraries that can work with both HM1.0 and
> 1.1, without having to maintain two different sources.
>
> Would it be possible to maintain some compatibility with HM1.1 in HM1.0, or
> would it be too big an effort (and not worthy?)?
>
> Cheers
>
> Jean-Francois
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
