Apparently we are allowed to modify the implementations to add new
functionality.
I would like to propose we modify the current implementation to search
for an implementation of HelperProvider using the JAR service lookup
mechanism. Users will then be able to use our API JAR with their choice
of implementation.
--
Jeremy
Jeremy Boynes wrote:
> I was looking to add a JavaHelper for the Tuscany implementation to help
> build up SDO types from Java interfaces but ran into a couple of issues.
> Can someone point me in the right direction?
>
> The HelperProvider factory constructs the implementation in a static
> initializer using:
>
> static HelperProvider INSTANCE = getHelperProviderImpl();
>
> static HelperProvider getHelperProviderImpl()
> {
> try
> {
> return
> (HelperProvider)Class.forName("commonj.sdo.impl.HelperProviderImpl").newInstance();
> } catch (Exception e)
> {
> throw new RuntimeException(e);
> }
> } // end method getHelperProvider()
>
> This basically forces the spec and implementation classes to be
> co-located in the same jar file (assuming the package is sealed) or at
> least in the same classloader (if not). I know this is meant to be the
> "default" implementation but wouldn't something like the JAR service
> mechanism be more flexible here?
>
> Further, all of the methods that get overridden by the implementation
> have also package protection on them so the only place an implemention
> can be placed is in the spec package. This includes the constructor for
> HelperProviderImpl so it would seem that the only instance available is
> the default one.
>
> Is the intention here that implementations include their own version of
> the spec classes in their jars? What happens if an application wants to
> use two different implementations with different characteristics, or if
> two applications in the same runtime use different versions? What is the
> best way for an implementation to provide additional helpers?
>
> --
> TIA, Jeremy
