avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: PR9270
Date Sun, 18 Aug 2002 09:22:50 GMT


Eung-ju Park wrote:

>----- Original Message -----
>From: "Stephen McConnell" <mcconnell@apache.org>
>To: "Avalon-Phoenix Developers List" <avalon-phoenix-dev@jakarta.apache.org>
>Sent: Sunday, August 18, 2002 3:04 PM
>Subject: Re: PR9270
>
>
>  
>
>>Eung-ju Park wrote:
>>
>>    
>>
>>>----- Original Message -----
>>>From: "Stephen McConnell" <mcconnell@apache.org>
>>>To: "Avalon-Phoenix Developers List"
>>>      
>>>
><avalon-phoenix-dev@jakarta.apache.org>
>  
>
>>>Sent: Sunday, August 18, 2002 7:42 AM
>>>Subject: Re: PR9270
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>Should this be at the meta-data level (as your proposing) or the
>>>>meta-info level?  I think it would be more appropriate for the
>>>>inforation to go into the blockinfo (in Phoenix) or as a component
>>>>attribute in the Type DTD.
>>>>
>>>>
>>>>        
>>>>
>>>I think it it meta-data. It specified by assembler, not block developer.
>>>It is not about block it self. I think it is about block assembling.
>>>
>>>      
>>>
>>The existace of a component that is itself a proxy is a developer
>>decision.  For example, the org.omg.ORB class is a proxy to an
>>implementation.  The Java VM handles the loading of the implemetation
>>class behind the scenes.  But the developer needs to say to the
>>assembler - hey - watch out - this class is already a proxy.
>> Potentially, an assembler could be dealing with alternative
>>implentations of a particular service - one already a proxy, and another
>>an interface.  Is there an issue for the assembler - or is this an issue
>>for the container?  My feeling is that this is an issue between the
>>container and the componet - however, if it is an assembler issue, then
>>the question for the assemble is if a proxy class is allowed or not.
>> However, I doubt if this is a valid assembler question.  The only thing
>>I can think of as an issue is if the class implements lifecyle
>>interfaces that could be potentially absused and as a result, raise a
>>security implication.
>>    
>>
>
>Yes. disabling proxy causes security problem. It is tradeoff.
>Trade off performance and security.
>I think enable/disable proxy is just assembler issue. 
>

Agreed.
The assemble should control the "policy" of proxy enforcement (do I 
enable components that cannot be proxied YES/NO)
The componet type should be declaring the constraint (*can I be managed 
as a proxy - YES/NO).
This provides a clean seperation of concerns.

>Because current
>proxy's feature is just export only permitted service interfaces.
>
>PS. Sorry for my poor English.
>I don't understand your opinion fully. 
>

I have a bad habid of writting overly complex stuff - no appologies 
necessary!

>And don't expressing my opinion correctly.
>  
>

It's cool - you should see my written French!


>  
>
>>Cheers, Steve.
>>
>>
>>
>>    
>>
>>>--
>>>To unsubscribe, e-mail:
>>>      
>>>
><mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
>  
>
>>>For additional commands, e-mail:
>>>      
>>>
><mailto:avalon-phoenix-dev-help@jakarta.apache.org>
>  
>
>>>
>>>      
>>>
>>--
>>
>>Stephen J. McConnell
>>
>>OSM SARL
>>digital products for a global economy
>>mailto:mcconnell@osm.net
>>http://www.osm.net
>>
>>
>>
>>
>>--
>>To unsubscribe, e-mail:
>>    
>>
><mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
>  
>
>>For additional commands, e-mail:
>>    
>>
><mailto:avalon-phoenix-dev-help@jakarta.apache.org>
>  
>
>>    
>>
>
>
>--
>To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>


Mime
View raw message