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?
Phil
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
