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

[Valery Kokhan <vkokhan@xxxxxxxxxxxxxx>]

I agree that there is a dynamic way but as you mention you'll need the
permission for that and... this may not always be possible...

-- 
Best regards,

Valery

Tuesday, October 31, 2006, 6:12:16 PM, you wrote:

>  
> 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
>  
>  
>