[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: Re[4]: [higgins-dev] [IdAS] registry factoring
|
I would rater error on the side that requires an action then to have no built in security
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 11:53 AM
Please respond to
Valery Kokhan <vkokhan@xxxxxxxxxxxxxx> |
|
|
I'm not argue that permission's mechanism is a good thing. If it is
*my* JVM I do not see any problems but have you ever try to explain to
not very advanced users how to grant some permission?
--
Best regards,
Valery
Tuesday, October 31, 2006, 6:56:18 PM, you wrote:
>
> 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
> Valery Kokhan <vkokhan@xxxxxxxxxxxxxx>
>
>
>
>
>
>
>
> Valery Kokhan <vkokhan@xxxxxxxxxxxxxx>
> 10/31/2006 10:29 AM
> Please respond to
> Valery Kokhan <vkokhan@xxxxxxxxxxxxxx>
>
>
> To
> Anthony Nadalin/Austin/IBM@IBMUS
>
> cc
> "Higgins (Trust Framework) Project developer discussions"
> <higgins-dev@xxxxxxxxxxx>, Greg Byrd <gbyrd@xxxxxxxx>,
> <higgins-dev-bounces@xxxxxxxxxxx>, Igor Tsinman
> <itsinman@xxxxxxxxxxxxx>, Vadym Synakh <synakh@xxxxxxxxxxxxxx>
>
> Subject
> Re[2]: [higgins-dev] [IdAS] registry factoring
> 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
>>
>>
>>
>
>
>
>
