commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject [id] Re: Commons-Id component ?
Date Sat, 01 May 2004 15:26:40 GMT

I am forwarding this to commons-dev, so we can discuss the [id] design issues.

> Well, ... yes :) In my case I am not interested in the factory at all,
> because all I need is a IdentifierGenerator and my app don't care about
> the type of the generated keys unless they are unique even using
> persistance. If you have special requirements for the key type, you
> have to preselect.
> Personally I am not sure, what's the real use case of the Factory. At
> first glance it seems to provide you with the "default" implementation
> of the different generator types in the package, but offers then a
> single method for nearly every generator type in the package (and add
> all the dependencies to your app). Is there really an advantage instead
> of calling the ctor directly ? ... but that's not my topic here.

The idea is that you could substitute a different concrete factory using 
the discovery mechanism.  We have talked about ripping this out / 
simplifying the implementation.  Ideas for improvement (still holding on 
to the strategy pattern) are welcome.

> For the generators itself it would be nice if it is possible to
> register one of them easily based on configuration, so you'll have
> pico.registerComponentInstance(IdentifierGenerator.class,
> XXXGenerator.class);
> Side note to Phil: Requesting Pico for an IdentifierGenerator instance
> it would then instantiate the specified generator and resolve all
> dependencies of the ctor. While this is possible for most of the
> Generators, this does not work for the very interesting UUIDGenerators,
> since they are implemented using a singleton pattern and their ctors
> are private. I understand the background of the decision, but Pico will
> return in the case above every time the same instance and from a
> logical point of view I have the singleton also.

Another valid point which we have discussed and which you will notice is 
not consistent with the way that, e.g. SessionIdGenerator is implemented. 
I was ambivalent (as Tim was as well, IIRC) about this design decision.
> From a technical point of view, instances of the UUIDGenerators don't
> have to be singletons either, unless they use the same internal
> instance. In case of VersionFourGenerator you store the Random instance
> in a static member anyway, you may also initialize it within a static
> initializer instead within the ctor. Same case applies to
> VersionOneGenerator, make the manager static, initialize it in the ctor
> if you don't have an instance yet and synchronize on the manager in
> nextUUID. Then you're able to have as much instances of the generators
> as you like without breaking the underlaying specification. But since
> this is more a design decision, I don't know if you really like this.
> Otherwise I can provide patches.

I think that this would be an improvement, unless I am missing something. 
   Tim, can you see anything wrong with this?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message