Re[2]: [higgins-dev] [IdAS] registry factoring

[Valery Kokhan <valery@xxxxxxxxxxxxx>]

Hi Greg,

Personally, I think that your registry code should be a part of
current IdAS project. If you take a look at current IdAS project you
may notice that all plugin's specific code (actually just one class
for now) is separated in *.idas.internal.plugin package(s). That
package(s) just excluded from the build process for standard jar. If
you put your plugin's specific code into "plugin" package or its
sub-packages it'll be automatically excluded as well.

-- 
Best regards,

Valery

Tuesday, October 31, 2006, 5:50:58 PM, you wrote:

> Replies in-line.
>>
>> Because we're going to produce two versions of IdAS - plugin and
>> standard jar both from the same project, we need to be able to
>> register IdAS providers in two ways.
>>
>>   
> Agreed.  I was worried about introducing Eclipse dependencies in the 
> project, because I don't know how to filter those out (and not compile
> the Ext class that you describe below) for a non-plugin jar.  If someone
> else knows how to do this, I won't worry  about it.


>> It seems to me that standard java.security.Security mechanism may be
>> not the best choice to implement our registry for standard jars - the
>> problem is that such approach requires each provider to be registered
>> via java security file but this may not always be possible and so, it
>> is not very good for pluggable at runtime architecture.
>>
>> Personally, I think it'll be better to use
>> javax.imageio.spi.ServiceRegistry mechanism which was initially
>> designed for pluggable at runtime architecture. Although main purpose
>> of ServiceRegistry was pluggabe image IO, it widely used by Sun's JDK
>> implementation for other registry purposes as well.
>>
>>   

> It wouldn't be required for a provider to be in the java security file,
> because we also allow run-time registration.  But I'll take a look at 
> the ServiceRegistry mechanism.

>> As for the best way to separate...
>>
>>   
> <snip>

> I was working toward a similar solution (except for names -- what's an
> IdASServiceProvider?).  Your proposal has an assumption that there is 
> one and only one IdASRegistry object (per JVM).  Do others think that's
> the right assumption?  (I wasn't going to assume that, but I'm open to it.)

> ...Greg