[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: Re[2]: [higgins-dev] [IdAS] registry factoring
|
The permission is what keeps rouge provides from being added, if this is your JVM then you should have the permission, this is basically how JCE, JASS, JGSS framework work, its light weight and in the core of the JVM.
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
![Inactive hide details for Valery Kokhan <vkokhan@xxxxxxxxxxxxxx>]()
Valery Kokhan <vkokhan@xxxxxxxxxxxxxx>
Valery Kokhan <vkokhan@xxxxxxxxxxxxxx>
10/31/2006 10:29 AM
Please respond to
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
>
>
>
