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

[Anthony Nadalin <drsecure@xxxxxxxxxx>]

Not following you as "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" is not true as there is a static and dynamic registration, so you don't need static, everything could be dynamic (if you have the permission to add providers).

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Valery Kokhan <valery@xxxxxxxxxxxxx>

Valery Kokhan <valery@xxxxxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx

10/31/2006 09:35 AM

Please respond to
Valery Kokhan <vkokhan@xxxxxxxxxxxxxx>; Please respond to
"Higgins \(Trust Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx>

To	Greg Byrd <gbyrd@xxxxxxxx>
cc	Igor Tsinman <itsinman@xxxxxxxxxxxxx>, Vadym Synakh <synakh@xxxxxxxxxxxxxx>, "Higgins \(Trust Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx>
Subject	Re: [higgins-dev] [IdAS] registry factoring

Hi Greg,

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.

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.

As for the best way to separate...

My personal feeling is that our plug-in's registry should
extends (and consume) registry for standard jars.

Consider we have our implementation as follows:
1. Standard registry
class IdASRegistry {
        protected static IdASRegistry instance;

        public static IdASRegistry getDefaultInstance() {
                if (instance == null) {
                        instance = new IdASRegistry();
                }
                return instance;
        }

        protected IdASRegistry() {
                ...
        }

        public Iterator<IdASServiceProvider> getIdASServiceProviders() {
                ...
        }

        public IdASServiceProvider getIdASServiceProvider(String extID) {
               ...
        }
}

2. Plug-in registry (mainly uses Eclipse extension point mechanism but
try to consume any results from its base class as well)

class IdASRegistryExt extends IdASRegistry {

        // this method should be called by plugin's activator start()
        // method
        public static void initialize() {
                instance = new IdASRegistryExt();
        }

        private IdASRegistryExt() {
                ...
        }
        
        public Iterator<IdASServiceProvider> getIdASServiceProviders() {
               ...
               supper.getIdASServiceProviders();
        }

        public IdASServiceProvider getIdASServiceProvider(String extID) {
               ...
               if (result == null) {
                  result = supper.getIdASServiceProvider(extID);
               }
               return result;
        }
}

In such way IdAS consumers will use IdASRegistry instance returned by
IdASRegistry.getDefaultInstance() method regardless of runtime
environment.

-- 
Best regards,

Valery

Monday, October 30, 2006, 3:53:30 PM, you wrote:

> I'm trying to decide on the best way to separate the Eclipse 
> functionality (searching for ContextFactory plugins) from the standard
> Java functionality (searching the Security.getProviders() list).  My 
> current code does both, and therefore has Eclipse dependencies.  But I'm
> not sure how the non-Eclipse build is going to be structured.

> Should I create plugin and non-plugin versions of IdASRegistry?  The 
> plugin version would (of course) search for factory plugins, while the
> non-plugin version wouldn't.  (And the plugin version would be in its 
> own project to simplify the build.)

> ...Greg

> PS. I'm very sorry about the holdup on committing the registry code.  
> We're working on it.


> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev