You are viewing a plain text version of this content. The canonical link for it is here.
Posted to phoenix-dev@avalon.apache.org by Eung-ju Park <co...@apache.org> on 2002/08/17 16:31:20 UTC
PR9270
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9270
How about below configuration?
at assembly.xml
<block
class="org.apache.avalon.cornerstone.blocks.scheduler.DefaultTimeScheduler"
name="scheduler">
<proxy disable="true"/>
<provide name="thread-manager"
role="org.apache.avalon.cornerstone.services.threads.ThreadManager" />
</block>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PR9270
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Sun, 18 Aug 2002 17:32, Stephen McConnell wrote:
>
>
>>>You have stated that Merlin can read the CK DTD so there should be no
>>>problem about interoperability. Any component that wants to interoperate
>>>will use the CK DTD.
>>>
>>>
>>Only as a subset.
>>Promoting containerkit DTD means that your obliging ever other container
>>to handle the special case of the blockinfo DTD and the containerkit DTD
>>while Phoenix conviniently ignores the Type DTD. Would it not be more
>>efficient if we all used the same DTD?
>>
>>
>
>It would be more efficient but it is unlikely to happen while you want to
>support stages/extensions. Removing them will basically end up with CK DTD.
>Thus I don't really see any issue with using the CK DTD. The components which
>need to be interoperable will use it, those that don't - wont.
>
The interest in supporting stages/extensions is a matter for Phoenix -
its not an argument for excluding content from the common DTD. Phoenix
could/should/can work perfectly with the Type DTD. The containerkit API
could/should/can be built with the type DTD. You cannot say the same
for the containerkit DTD. The resulting metainfo model is constrained by
the fact that containerkit does not provide the extensions declaration
and as such it's insuffient. In practice the issues rest with the
respective containers. When phoenix marshals a xinfo description it can
reject a componet declaring an extension - just as Merlin can
reject/ignore management access points. This is a very small overhead
relative to the benefit of a common DTD.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PR9270
Posted by Peter Donald <pe...@apache.org>.
On Sun, 18 Aug 2002 17:32, Stephen McConnell wrote:
> >You have stated that Merlin can read the CK DTD so there should be no
> > problem about interoperability. Any component that wants to interoperate
> > will use the CK DTD.
>
> Only as a subset.
> Promoting containerkit DTD means that your obliging ever other container
> to handle the special case of the blockinfo DTD and the containerkit DTD
> while Phoenix conviniently ignores the Type DTD. Would it not be more
> efficient if we all used the same DTD?
It would be more efficient but it is unlikely to happen while you want to
support stages/extensions. Removing them will basically end up with CK DTD.
Thus I don't really see any issue with using the CK DTD. The components which
need to be interoperable will use it, those that don't - wont.
--
Cheers,
Peter Donald
----------------------------------------------
Money is how people with no talent keep score.
----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PR9270
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Sun, 18 Aug 2002 17:08, Stephen McConnell wrote:
>
>
>>>It hasn't seen enough testing. Post release I will integrate the
>>>containerkit config in as default and deprecate the old format. It will
>>>then be possible to experiment with addition of things like that.
>>>
>>>
>>How about integrating the Type DTD instread of containekit. This will
>>ensure smoother integration between Fortress, Merlin and Phoenix. Are
>>there really and issues with the Type DTD ?
>>
>>
>
>Yep. The bits that differ from CK DTD (stage and extension definitions) are
>untested in real world application and bind to container specific
>assumptions.
>
I disagee on this point. The mode for extensions is based on the work
from two independent containers. There is nothing container specific
about the DTD. There is nothing containber specific about the API.
Going back to the question I raised - the point is - can we use a
common DTD - forget about the API - just think about the DTD. I've
updated the Type DTD to cover everything in Phoenix, containerkit and
Merlin. It represents the superset of information
>These assumptions are things I happen to disagree with and have
>been tried before without success. Some of the things you are supporting have
>actually been in phoenix before and after the mess they made I doubt anyone
>would want to go back to that.
>
In practice these have been Phoenix implementation isues. After all,
Phoenix was not designed to suppoot the deployment of components to
support its own bootstrap process. Attempts to tweak Phoenix to handle
this sort of thing were unsucessful becuae you were retrofitting
lifestyle behaviour into the core. In the case of Merlin and Fortress
the management of lifestyle extensions is quite strait forward and
relatively small in terms of code. In the case of Merlin it has been
validated in real applications.
However - this isnt the poiont - the question addressed the potential
for a common DTD.
Can we forget about the API and just focus on the DTD for a moment ?
>
>You have stated that Merlin can read the CK DTD so there should be no problem
>about interoperability. Any component that wants to interoperate will use the
>CK DTD.
>
Only as a subset.
Promoting containerkit DTD means that your obliging ever other container
to handle the special case of the blockinfo DTD and the containerkit DTD
while Phoenix conviniently ignores the Type DTD. Would it not be more
efficient if we all used the same DTD?
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PR9270
Posted by Peter Donald <pe...@apache.org>.
On Sun, 18 Aug 2002 17:08, Stephen McConnell wrote:
> >It hasn't seen enough testing. Post release I will integrate the
> > containerkit config in as default and deprecate the old format. It will
> > then be possible to experiment with addition of things like that.
>
> How about integrating the Type DTD instread of containekit. This will
> ensure smoother integration between Fortress, Merlin and Phoenix. Are
> there really and issues with the Type DTD ?
Yep. The bits that differ from CK DTD (stage and extension definitions) are
untested in real world application and bind to container specific
assumptions. These assumptions are things I happen to disagree with and have
been tried before without success. Some of the things you are supporting have
actually been in phoenix before and after the mess they made I doubt anyone
would want to go back to that.
You have stated that Merlin can read the CK DTD so there should be no problem
about interoperability. Any component that wants to interoperate will use the
CK DTD.
--
Cheers,
Peter Donald
-----------------------------------------------
| If you turn on the light quickly enough, |
| you can see what the dark looks like. |
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PR9270
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Sun, 18 Aug 2002 16:29, Stephen McConnell wrote:
>
>
>>Peter Donald wrote:
>>
>>
>>>On Sun, 18 Aug 2002 16:14, Stephen McConnell wrote:
>>>
>>>
>>>>Would you like to address the issue of a component implementation that
>>>>is already a proxy?
>>>>This isn't meta-data, its meta-info. See SUN JDK Javadoc for the
>>>>org.omg.CORBA.ORB class for a practicle example.
>>>>
>>>>
>>>It will be better supported in the future when we move to a more complete
>>>meta info system but for now it is easies and most useful to just support
>>>notion of interceptor chains on components.
>>>
>>>
>>What about adding the Attributes type to the blockinfo. This would
>>enable the meta-info model used in Phoenix to pull out the information
>>in a manner consitent with the Type DTD, and the containerki DTDt. No
>>furture changes would be required and we would be eliminating an
>>artificial obligation of the assembler having to know about a component
>>implementation characteristic.
>>
>>
>
>It hasn't seen enough testing. Post release I will integrate the containerkit
>config in as default and deprecate the old format. It will then be possible
>to experiment with addition of things like that.
>
>
How about integrating the Type DTD instread of containekit. This will
ensure smoother integration between Fortress, Merlin and Phoenix. Are
there really and issues with the Type DTD ?
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PR9270
Posted by Peter Donald <pe...@apache.org>.
On Sun, 18 Aug 2002 16:29, Stephen McConnell wrote:
> Peter Donald wrote:
> >On Sun, 18 Aug 2002 16:14, Stephen McConnell wrote:
> >>Would you like to address the issue of a component implementation that
> >>is already a proxy?
> >>This isn't meta-data, its meta-info. See SUN JDK Javadoc for the
> >>org.omg.CORBA.ORB class for a practicle example.
> >
> >It will be better supported in the future when we move to a more complete
> > meta info system but for now it is easies and most useful to just support
> > notion of interceptor chains on components.
>
> What about adding the Attributes type to the blockinfo. This would
> enable the meta-info model used in Phoenix to pull out the information
> in a manner consitent with the Type DTD, and the containerki DTDt. No
> furture changes would be required and we would be eliminating an
> artificial obligation of the assembler having to know about a component
> implementation characteristic.
It hasn't seen enough testing. Post release I will integrate the containerkit
config in as default and deprecate the old format. It will then be possible
to experiment with addition of things like that.
--
Cheers,
Peter Donald
--------------------------------------------------
"An intellectual is someone who has been educated
beyond their intelligence."
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PR9270
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Sun, 18 Aug 2002 16:14, Stephen McConnell wrote:
>
>
>>Would you like to address the issue of a component implementation that
>>is already a proxy?
>>This isn't meta-data, its meta-info. See SUN JDK Javadoc for the
>>org.omg.CORBA.ORB class for a practicle example.
>>
>>
>
>It will be better supported in the future when we move to a more complete meta
>info system but for now it is easies and most useful to just support notion
>of interceptor chains on components.
>
>
What about adding the Attributes type to the blockinfo. This would
enable the meta-info model used in Phoenix to pull out the information
in a manner consitent with the Type DTD, and the containerki DTDt. No
furture changes would be required and we would be eliminating an
artificial obligation of the assembler having to know about a component
implementation characteristic.
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PR9270
Posted by Peter Donald <pe...@apache.org>.
On Sun, 18 Aug 2002 16:14, Stephen McConnell wrote:
> Would you like to address the issue of a component implementation that
> is already a proxy?
> This isn't meta-data, its meta-info. See SUN JDK Javadoc for the
> org.omg.CORBA.ORB class for a practicle example.
It will be better supported in the future when we move to a more complete meta
info system but for now it is easies and most useful to just support notion
of interceptor chains on components.
--
Cheers,
Peter Donald
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PR9270
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Sun, 18 Aug 2002 00:31, Eung-ju Park wrote:
>
>
>>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9270
>>
>>How about below configuration?
>>
>>at assembly.xml
>>
>> <block
>>class="org.apache.avalon.cornerstone.blocks.scheduler.DefaultTimeScheduler"
>>name="scheduler">
>> <proxy disable="true"/>
>> <provide name="thread-manager"
>>
>>role="org.apache.avalon.cornerstone.services.threads.ThreadManager" />
>> </block>
>>
>>
>
>Works for me. Or alternatively it could be something like
>
><interceptors include-default="false">
></interceptors>
>
>That way the extensions that Igor has been discussing could be easily added
>via something like
>
><interceptors include-default="false">
> <interceptor class="com.thinkdynamics.interceptors.LoggingInterceptor"/>
></interceptors>
>
>
>
Pete:
Would you like to address the issue of a component implementation that
is already a proxy?
This isn't meta-data, its meta-info. See SUN JDK Javadoc for the
org.omg.CORBA.ORB class for a practicle example.
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PR9270
Posted by Peter Donald <pe...@apache.org>.
On Sun, 18 Aug 2002 16:34, Eung-ju Park wrote:
> proxy with interceptors
> -----------------------
> <block
>
> class="org.apache.avalon.cornerstone.blocks.scheduler.DefaultTimeScheduler"
> name="scheduler">
> <provide .../>
> <proxy>
> <interceptor
> class="com.thinkdynamics.interceptors.LoggingInterceptor"/>
> </proxy>
> </block>
>
> disable proxy.
> -----------------------
> <block
>
> class="org.apache.avalon.cornerstone.blocks.scheduler.DefaultTimeScheduler"
> name="scheduler">
> <provide .../>
> <proxy disable="true"/>
> </block>
>
> Above is my initial concept.
> thought?
I like it !
--
Cheers,
Peter Donald
---------------------------------------------------
"It is easy to dodge our responsibilities, but we
cannot dodge the consequences of dodging our
responsibilities." -Josiah Stamp
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PR9270
Posted by Stephen McConnell <mc...@apache.org>.
Only works if the assembler has implementation knowlege of the component.
This means that a componet written without knowlege of a particular
container will not run inside Phoenix.
Steve.
Eung-ju Park wrote:
>----- Original Message -----
>From: "Peter Donald" <pe...@apache.org>
>To: "Avalon-Phoenix Developers List" <av...@jakarta.apache.org>
>Sent: Sunday, August 18, 2002 3:28 PM
>Subject: Re: PR9270
>
>
>On Sun, 18 Aug 2002 16:12, Peter Donald wrote:
>
>
>><interceptors include-default="false">
>> <interceptor class="com.thinkdynamics.interceptors.LoggingInterceptor"/>
>></interceptors>
>>
>>Actually this could be a bad idea. Because what does the above mean (with
>>default interceptors="false" but definining an interceptor.
>>
>>Maybe it is better to go with something more simple like
>>
>><block
>>
>>
>>
>class="org.apache.avalon.cornerstone.blocks.scheduler.DefaultTimeScheduler"
>
>
>> name="scheduler"
>> proxy="false">
>> <provide .../>
>></block>
>>
>>Then when we add interceptor definitions later on we can raise an
>>
>>
>exception if
>
>
>>proxy is false but interceptors are defined ?
>>
>>
>
>proxy with interceptors
>-----------------------
><block
>
>class="org.apache.avalon.cornerstone.blocks.scheduler.DefaultTimeScheduler"
> name="scheduler">
> <provide .../>
> <proxy>
> <interceptor
>class="com.thinkdynamics.interceptors.LoggingInterceptor"/>
> </proxy>
></block>
>
>disable proxy.
>-----------------------
><block
>
>class="org.apache.avalon.cornerstone.blocks.scheduler.DefaultTimeScheduler"
> name="scheduler">
> <provide .../>
> <proxy disable="true"/>
></block>
>
>Above is my initial concept.
>thought?
>
>--
>Cheers,
>
>Peter Donald
>*------------------------------------------------*
>| Trying is the first step to failure. |
>| So never try, Lisa - Homer Jay Simpson |
>*------------------------------------------------*
>
>
>--
>To unsubscribe, e-mail:
><ma...@jakarta.apache.org>
>For additional commands, e-mail:
><ma...@jakarta.apache.org>
>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PR9270
Posted by Eung-ju Park <co...@apache.org>.
----- Original Message -----
From: "Peter Donald" <pe...@apache.org>
To: "Avalon-Phoenix Developers List" <av...@jakarta.apache.org>
Sent: Sunday, August 18, 2002 3:28 PM
Subject: Re: PR9270
On Sun, 18 Aug 2002 16:12, Peter Donald wrote:
> <interceptors include-default="false">
> <interceptor class="com.thinkdynamics.interceptors.LoggingInterceptor"/>
> </interceptors>
>
> Actually this could be a bad idea. Because what does the above mean (with
> default interceptors="false" but definining an interceptor.
>
> Maybe it is better to go with something more simple like
>
> <block
>
class="org.apache.avalon.cornerstone.blocks.scheduler.DefaultTimeScheduler"
> name="scheduler"
> proxy="false">
> <provide .../>
> </block>
>
> Then when we add interceptor definitions later on we can raise an
exception if
> proxy is false but interceptors are defined ?
proxy with interceptors
-----------------------
<block
class="org.apache.avalon.cornerstone.blocks.scheduler.DefaultTimeScheduler"
name="scheduler">
<provide .../>
<proxy>
<interceptor
class="com.thinkdynamics.interceptors.LoggingInterceptor"/>
</proxy>
</block>
disable proxy.
-----------------------
<block
class="org.apache.avalon.cornerstone.blocks.scheduler.DefaultTimeScheduler"
name="scheduler">
<provide .../>
<proxy disable="true"/>
</block>
Above is my initial concept.
thought?
--
Cheers,
Peter Donald
*------------------------------------------------*
| Trying is the first step to failure. |
| So never try, Lisa - Homer Jay Simpson |
*------------------------------------------------*
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PR9270
Posted by Peter Donald <pe...@apache.org>.
On Sun, 18 Aug 2002 16:12, Peter Donald wrote:
> <interceptors include-default="false">
> <interceptor class="com.thinkdynamics.interceptors.LoggingInterceptor"/>
> </interceptors>
Actually this could be a bad idea. Because what does the above mean (with
default interceptors="false" but definining an interceptor.
Maybe it is better to go with something more simple like
<block
class="org.apache.avalon.cornerstone.blocks.scheduler.DefaultTimeScheduler"
name="scheduler"
proxy="false">
<provide .../>
</block>
Then when we add interceptor definitions later on we can raise an exception if
proxy is false but interceptors are defined ?
--
Cheers,
Peter Donald
*------------------------------------------------*
| Trying is the first step to failure. |
| So never try, Lisa - Homer Jay Simpson |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PR9270
Posted by Peter Donald <pe...@apache.org>.
On Sun, 18 Aug 2002 00:31, Eung-ju Park wrote:
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9270
>
> How about below configuration?
>
> at assembly.xml
>
> <block
> class="org.apache.avalon.cornerstone.blocks.scheduler.DefaultTimeScheduler"
> name="scheduler">
> <proxy disable="true"/>
> <provide name="thread-manager"
>
> role="org.apache.avalon.cornerstone.services.threads.ThreadManager" />
> </block>
Works for me. Or alternatively it could be something like
<interceptors include-default="false">
</interceptors>
That way the extensions that Igor has been discussing could be easily added
via something like
<interceptors include-default="false">
<interceptor class="com.thinkdynamics.interceptors.LoggingInterceptor"/>
</interceptors>
--
Cheers,
Peter Donald
*------------------------------------------------*
| Trying is the first step to failure. |
| So never try, Lisa - Homer Jay Simpson |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PR9270
Posted by Stephen McConnell <mc...@apache.org>.
Eung-ju Park wrote:
>----- Original Message -----
>From: "Stephen McConnell" <mc...@apache.org>
>To: "Avalon-Phoenix Developers List" <av...@jakarta.apache.org>
>Sent: Sunday, August 18, 2002 3:04 PM
>Subject: Re: PR9270
>
>
>
>
>>Eung-ju Park wrote:
>>
>>
>>
>>>----- Original Message -----
>>>From: "Stephen McConnell" <mc...@apache.org>
>>>To: "Avalon-Phoenix Developers List"
>>>
>>>
><av...@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:
>>>
>>>
><ma...@jakarta.apache.org>
>
>
>>>For additional commands, e-mail:
>>>
>>>
><ma...@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:
>>
>>
><ma...@jakarta.apache.org>
>
>
>>For additional commands, e-mail:
>>
>>
><ma...@jakarta.apache.org>
>
>
>>
>>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PR9270
Posted by Eung-ju Park <co...@apache.org>.
----- Original Message -----
From: "Stephen McConnell" <mc...@apache.org>
To: "Avalon-Phoenix Developers List" <av...@jakarta.apache.org>
Sent: Sunday, August 18, 2002 3:04 PM
Subject: Re: PR9270
>
>
> Eung-ju Park wrote:
>
> >----- Original Message -----
> >From: "Stephen McConnell" <mc...@apache.org>
> >To: "Avalon-Phoenix Developers List"
<av...@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. 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. And don't expressing my opinion
correctly.
>
> Cheers, Steve.
>
>
>
> >
> >--
> >To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> >For additional commands, e-mail:
<ma...@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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PR9270
Posted by Stephen McConnell <mc...@apache.org>.
Eung-ju Park wrote:
>----- Original Message -----
>From: "Stephen McConnell" <mc...@apache.org>
>To: "Avalon-Phoenix Developers List" <av...@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.
Cheers, Steve.
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PR9270
Posted by Eung-ju Park <co...@apache.org>.
----- Original Message -----
From: "Stephen McConnell" <mc...@apache.org>
To: "Avalon-Phoenix Developers List" <av...@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.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PR9270
Posted by Stephen McConnell <mc...@apache.org>.
Eung-ju Park wrote:
>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9270
>
>How about below configuration?
>
>at assembly.xml
>
> <block
>class="org.apache.avalon.cornerstone.blocks.scheduler.DefaultTimeScheduler"
>name="scheduler">
> <proxy disable="true"/>
> <provide name="thread-manager"
>
>role="org.apache.avalon.cornerstone.services.threads.ThreadManager" />
> </block>
>
>
>
>
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.
For example:
<type>
<component>
<name>my-component</name>
<attributes>
<attribute key="avalon:proxy-generation" value="false"/>
</attributes>
</component>
</type>
Cheers, Steve.
>
>
>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>