> > thus you just need to sub-class ObjectFactory and override some
> > createXXX methods to use your sub-classes instead of the
>
> [ ... ]
>
> > No, in general you shouldn't sub-class the ObjectFactory class because
> > it's highly implementation-dependent.
>
> Isn't that a contradiction?
I'm sorry, I just mixed up the RI specific part and the spec part.
The spec says the ObjectFactory class will have non-static createXXX
methods. This is a portable part.
The next release of RI (hopefully) generates the code in such a way that
the user can override those methods to specify sub-classes (I'm not 100%
sure since we didn't try it by ourselves, but we had this in mind.) This
is the RI-specific part.
> In other words: You may replace the automatically generated classes
> with suitable subclasses or different implementations matching the
> same interfaces.
I suppose that's also a feasible approach. My point is that at the
implementation level, there are ways to achieve this, and RI is trying
to have one, but at the same time it's hard to do it in a generic enough
way so that it can be used by very different implementation techniques.
For example, the whole concept of sub-classing a generated
implementation class won't work if the implementation classes are
generated on-the-fly at the runtime.
regards,
--
Kohsuke KAWAGUCHI 408-276-7063 (x17063)
Sun Microsystems kohsuke.kawaguchi_at_sun.com