You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2002/09/17 23:07:05 UTC
Context Keys Proposal Change
The link on the web site:
http://jakarta.apache.org/avalon/excalibur/container/attributes.html
Has two context keys defined an done attribute defined. Obviously this
is not enough, but we need to get to the proper abstractions. Anyway,
here are some changes that need to be performed:
CONTEXT
Key Type Description
----------- ---------------- -------------------------------------
avalon:home java.net.URL This is a context directory that may
contain a bunch of files that a
component needs to do its work. There
is NO GUARANTEE that the URL is
writable.
avalon:work java.io.File This is a work directory that the
component may use as a work area. This
directory MUST be writable.
avalon:name java.lang.String The name of a component (is this
really necessary?)
ATTRIBUTES
avalon:lifestyle (SINGLETON|THREAD|POOL|TRANSIENT) Currently
sufficient, but I am awaiting more info
on Peter's proposals.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context Keys Proposal Change
Posted by Leo Simons <le...@apache.org>.
> >>>>avalon:name java.lang.String The name of a component (is this
> >>>> really necessary?)
> >>>
> >>>
> >>>+1. Seems useful to me (wrt logging, GUIs, etc). Regardless, I doubt
> >>>anyone would ever want to attach a different class or meaning to
> >>>"avalon:name" so I doubt it will lead to problems.
> >>
> >>Well, with logging the category can be assigned to the "avalon:name",
> >>and management GUIs would have another way to access that information.
> >>So my point is why would we need it to solve real problems?
> >
> >
> > that doesn't compute....could you elaborate a bit...it seems to me if
> > you want to assign the category to avalon:name, you should define
> > avalon:name....?
>
> The container sets the Logger, and therefore the category for the
> Component. The component does not need to know what its name is to
> create child loggers either because it can perform this:
>
> Logger classLoaderLogger = getLogger().getChildLogger( "classloader" );
> m_myLoader.setLogger( classLoaderLogger );
>
> In fact, that is prefered to explicitly setting the category because
> logging is performed within the scope that the container wants it
> performed.
when your component crosses problem boundaries (of which the container
may not be aware, ie remoting 'n stuff), the component will need to
identify itself to a caller and/or callee in some way.
Another such issue is wrt to i18n. In many systems it is cumbersome to
make dealing with that the task of the container, whereas it is usually
easy to resource the components.
> I still don't see any *compelling* reason to expose the component's
> name to itself. There is nothing it can do programatically.
yep. But what it can do is provide this information to "userspace",
where it is perfectly viable for the component doing so directly instead
of through the container.
> The
> Logging category is set by the container, not the component. GUIs can
> get at the name through other mechanisms than the component itself. In
> fact, I would have a hard time justifying exposing *all* components to a
> GUI.
Think of a GUI manager for InfoMover...you'd want to expose components.
Think of JMX support in phoenix...that's all about (well also about)
exposing components.............I suspect we're thinking different
things here...
I wasn't completely sure we needed avalon:name before; I am now =)
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context Keys Proposal Change
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> Leo Sutic wrote:
> >
> >>From: Berin Loritsch [mailto:bloritsch@apache.org]
> >>
> >
> >>>to pass information on which a reasonably elegant message can be
> >>>generated on a remote system. This message is outside any logging
> >>>context and naming strucrture implied by a containment hierachy.
> >>>Cheers, Steve.
> >>
> >>Ok. That is a compelling enough reason.
> >
> >
> > Should that really be passed in via the context? I'd prefer a
> > configuration entry or:
> >
> > public interface Nameable {
> > public void setName (String name);
> > }
>
> -1. While such a solution could be hacked together using
> extensions, we shouldn't clutter an already detailed
> lifecycle with something as trivial as this. It is perfectly
> acceptable for the name to be propogated using the Context
> object.
OK, agree.
What I was thinking was that the name is only part of something
more - like a ContainerEntry or something. But then the ContainerEntry
would end up being the only object in the Context...
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context Keys Proposal Change
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
>
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>
>>>to pass information on which a reasonably elegant message can be
>>>generated on a remote system. This message is outside any logging
>>>context and naming strucrture implied by a containment hierachy.
>>>Cheers, Steve.
>>
>>Ok. That is a compelling enough reason.
>
>
> Should that really be passed in via the context? I'd prefer a
> configuration entry or:
>
> public interface Nameable {
> public void setName (String name);
> }
-1. While such a solution could be hacked together using extensions,
we shouldn't clutter an already detailed lifecycle with something as
trivial as this. It is perfectly acceptable for the name to be
propogated using the Context object. Stephen's argument is strong
enough to include it in the Context object, but not strong enough
to add yet another lifecycle interface for a component.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Context Keys Proposal Change
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: den 18 september 2002 17:18
> To: Avalon Developers List
> Subject: Re: Context Keys Proposal Change
>
>
> Stephen McConnell wrote:
> >
> >
> > Berin Loritsch wrote:
> >> In fact, that is prefered to explicitly setting the
> category because
> >> logging is performed within the scope that the container wants it
> >> performed.
> >>
> >> I still don't see any *compelling* reason to expose the
> component's
> >> name to itself.
> >
> >
> >
> > It is useful with respect to exception management. If you have
> > exceptions that are passed from one system to another, it
> is desirable
> > to pass information on which a reasonably elegant message can be
> > generated on a remote system. This message is outside any logging
> > context and naming strucrture implied by a containment hierachy.
> > Cheers, Steve.
>
> Ok. That is a compelling enough reason.
Should that really be passed in via the context? I'd prefer a
configuration entry or:
public interface Nameable {
public void setName (String name);
}
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context Keys Proposal Change
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>
> Berin Loritsch wrote:
>> In fact, that is prefered to explicitly setting the category because
>> logging is performed within the scope that the container wants it
>> performed.
>>
>> I still don't see any *compelling* reason to expose the component's
>> name to itself.
>
>
>
> It is useful with respect to exception management. If you have
> exceptions that are passed from one system to another, it is desirable
> to pass information on which a reasonably elegant message can be
> generated on a remote system. This message is outside any logging
> context and naming strucrture implied by a containment hierachy.
> Cheers, Steve.
Ok. That is a compelling enough reason.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context Keys Proposal Change
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Leo Simons wrote:
>
>> On Wed, 2002-09-18 at 15:19, Berin Loritsch wrote:
>>
>>> Leo Simons wrote:
>>>
>>>> On Tue, 2002-09-17 at 23:07, Berin Loritsch wrote:
>>>>
>>>>> avalon:name java.lang.String The name of a component (is this
>>>>> really necessary?)
>>>>
>>>>
>>>>
>>>> +1. Seems useful to me (wrt logging, GUIs, etc). Regardless, I doubt
>>>> anyone would ever want to attach a different class or meaning to
>>>> "avalon:name" so I doubt it will lead to problems.
>>>
>>>
>>> Well, with logging the category can be assigned to the "avalon:name",
>>> and management GUIs would have another way to access that information.
>>> So my point is why would we need it to solve real problems?
>>
>>
>>
>> that doesn't compute....could you elaborate a bit...it seems to me if
>> you want to assign the category to avalon:name, you should define
>> avalon:name....?
>
>
> The container sets the Logger, and therefore the category for the
> Component. The component does not need to know what its name is to
> create child loggers either because it can perform this:
>
> Logger classLoaderLogger = getLogger().getChildLogger( "classloader" );
> m_myLoader.setLogger( classLoaderLogger );
The avalon:name attribute has nothing to do with the logging. These are
completely different issues.
>
> In fact, that is prefered to explicitly setting the category because
> logging is performed within the scope that the container wants it
> performed.
>
> I still don't see any *compelling* reason to expose the component's
> name to itself.
It is useful with respect to exception management. If you have
exceptions that are passed from one system to another, it is desirable
to pass information on which a reasonably elegant message can be
generated on a remote system. This message is outside any logging
context and naming strucrture implied by a containment hierachy.
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: Context Keys Proposal Change
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
> On Wed, 2002-09-18 at 15:19, Berin Loritsch wrote:
>
>>Leo Simons wrote:
>>
>>>On Tue, 2002-09-17 at 23:07, Berin Loritsch wrote:
>>>
>>>>avalon:name java.lang.String The name of a component (is this
>>>> really necessary?)
>>>
>>>
>>>+1. Seems useful to me (wrt logging, GUIs, etc). Regardless, I doubt
>>>anyone would ever want to attach a different class or meaning to
>>>"avalon:name" so I doubt it will lead to problems.
>>
>>Well, with logging the category can be assigned to the "avalon:name",
>>and management GUIs would have another way to access that information.
>>So my point is why would we need it to solve real problems?
>
>
> that doesn't compute....could you elaborate a bit...it seems to me if
> you want to assign the category to avalon:name, you should define
> avalon:name....?
The container sets the Logger, and therefore the category for the
Component. The component does not need to know what its name is to
create child loggers either because it can perform this:
Logger classLoaderLogger = getLogger().getChildLogger( "classloader" );
m_myLoader.setLogger( classLoaderLogger );
In fact, that is prefered to explicitly setting the category because
logging is performed within the scope that the container wants it
performed.
I still don't see any *compelling* reason to expose the component's
name to itself. There is nothing it can do programatically. The
Logging category is set by the container, not the component. GUIs can
get at the name through other mechanisms than the component itself. In
fact, I would have a hard time justifying exposing *all* components to a
GUI.
The only *possible* argument would be for Instrumentation. However, we
already addressed that because the parent can add to the name of the
child instrument.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context Keys Proposal Change
Posted by Leo Simons <le...@apache.org>.
On Wed, 2002-09-18 at 15:19, Berin Loritsch wrote:
> Leo Simons wrote:
> > On Tue, 2002-09-17 at 23:07, Berin Loritsch wrote:
> >>avalon:name java.lang.String The name of a component (is this
> >> really necessary?)
> >
> >
> > +1. Seems useful to me (wrt logging, GUIs, etc). Regardless, I doubt
> > anyone would ever want to attach a different class or meaning to
> > "avalon:name" so I doubt it will lead to problems.
>
> Well, with logging the category can be assigned to the "avalon:name",
> and management GUIs would have another way to access that information.
> So my point is why would we need it to solve real problems?
that doesn't compute....could you elaborate a bit...it seems to me if
you want to assign the category to avalon:name, you should define
avalon:name....?
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context Keys Proposal Change
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
> On Tue, 2002-09-17 at 23:07, Berin Loritsch wrote:
>
>>Has two context keys defined an done attribute defined. Obviously this
>>is not enough, but we need to get to the proper abstractions. Anyway,
>>here are some changes that need to be performed:
>>
>>CONTEXT
>>
>>Key Type Description
>>----------- ---------------- -------------------------------------
>>avalon:home java.net.URL This is a context directory that may
>> contain a bunch of files that a
>> component needs to do its work. There
>> is NO GUARANTEE that the URL is
>> writable.
>
>
> +1
>
> thought: "directory" implies use of file:/// as the protocol. Is that
> part of the contract?
Nope. Consider the Servlet spec. When you get a file/resource out of
the supplied context you are not guaranteed what its protocol is. With
Tomcat, it happens to be the "file://" protocol, but with IBM WebSphere
it is "classloader://".
For containers that are embedded in a servlet environment like Cocoon,
we cannot assume "file://" will be the protocol--although nine times
out of ten it will be.
>
>
>>avalon:work java.io.File This is a work directory that the
>> component may use as a work area. This
>> directory MUST be writable.
>
>
> +1
>
> thought: we might want to add notions of isolation here as well (perhaps
> later on), in that it is guaranteed no other component will overwrite
> stuff here......
:) That is the general idea.
>>avalon:name java.lang.String The name of a component (is this
>> really necessary?)
>
>
> +1. Seems useful to me (wrt logging, GUIs, etc). Regardless, I doubt
> anyone would ever want to attach a different class or meaning to
> "avalon:name" so I doubt it will lead to problems.
Well, with logging the category can be assigned to the "avalon:name",
and management GUIs would have another way to access that information.
So my point is why would we need it to solve real problems?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context Keys Proposal Change
Posted by Leo Simons <ma...@leosimons.com>.
On Tue, 2002-09-17 at 23:07, Berin Loritsch wrote:
> Has two context keys defined an done attribute defined. Obviously this
> is not enough, but we need to get to the proper abstractions. Anyway,
> here are some changes that need to be performed:
>
> CONTEXT
>
> Key Type Description
> ----------- ---------------- -------------------------------------
> avalon:home java.net.URL This is a context directory that may
> contain a bunch of files that a
> component needs to do its work. There
> is NO GUARANTEE that the URL is
> writable.
+1
thought: "directory" implies use of file:/// as the protocol. Is that
part of the contract?
> avalon:work java.io.File This is a work directory that the
> component may use as a work area. This
> directory MUST be writable.
+1
thought: we might want to add notions of isolation here as well (perhaps
later on), in that it is guaranteed no other component will overwrite
stuff here......
> avalon:name java.lang.String The name of a component (is this
> really necessary?)
+1. Seems useful to me (wrt logging, GUIs, etc). Regardless, I doubt
anyone would ever want to attach a different class or meaning to
"avalon:name" so I doubt it will lead to problems.
> ATTRIBUTES
>
> avalon:lifestyle (SINGLETON|THREAD|POOL|TRANSIENT) Currently
> sufficient, but I am awaiting more info
> on Peter's proposals.
+1 for waiting with final definition / voting =)
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context Keys Proposal Change
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>>
>> Berin Loritsch wrote:
>>
>>> The link on the web site:
>>>
>>> http://jakarta.apache.org/avalon/excalibur/container/attributes.html
>>>
>>> avalon:name java.lang.String The name of a component (is this
>>> really necessary?)
>>
>>
>>
>>
>> It not "necessary" but it is convinient for two reasons. Firstly it
>> provides a hook to the component instance name assigned by a
>> container when having to deal with things like BlockContext.
>> Secondly, it is useful in error message generation by a component
>> implementation.
>
>
> Just keep in mind that under your proposal, a Component can go by many
> names. I have to assume that you are refering to the assembly.xml
> declared name as opposed to the lookup role name.
>
Basically correct - however, a componay can be created in Merlin without
explicit declaration at the assmbly level. For example, a componet
profile can be declared in a package. The package supplied name may
conflict with a name already declared at assembly scope in which case
the container needs to provide a non-confliciting name for the component
instance it is introducing.
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: Context Keys Proposal Change
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>
> Berin Loritsch wrote:
>
>> The link on the web site:
>>
>> http://jakarta.apache.org/avalon/excalibur/container/attributes.html
>>
>> avalon:name java.lang.String The name of a component (is this
>> really necessary?)
>
>
>
> It not "necessary" but it is convinient for two reasons. Firstly it
> provides a hook to the component instance name assigned by a container
> when having to deal with things like BlockContext. Secondly, it is
> useful in error message generation by a component implementation.
Just keep in mind that under your proposal, a Component can go by many
names. I have to assume that you are refering to the assembly.xml
declared name as opposed to the lookup role name.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context Keys Proposal Change
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> The link on the web site:
>
> http://jakarta.apache.org/avalon/excalibur/container/attributes.html
>
> Has two context keys defined an done attribute defined. Obviously this
> is not enough, but we need to get to the proper abstractions. Anyway,
> here are some changes that need to be performed:
>
> CONTEXT
>
> Key Type Description
> ----------- ---------------- -------------------------------------
> avalon:home java.net.URL This is a context directory that may
> contain a bunch of files that a
> component needs to do its work. There
> is NO GUARANTEE that the URL is
> writable.
+1
>
>
> avalon:work java.io.File This is a work directory that the
> component may use as a work area. This
> directory MUST be writable.
+1
>
> avalon:name java.lang.String The name of a component (is this
> really necessary?)
It not "necessary" but it is convinient for two reasons. Firstly it
provides a hook to the component instance name assigned by a container
when having to deal with things like BlockContext. Secondly, it is
useful in error message generation by a component implementation.
Cheers, Steve.
>
>
> ATTRIBUTES
>
> avalon:lifestyle (SINGLETON|THREAD|POOL|TRANSIENT) Currently
> sufficient, but I am awaiting more info
> on Peter's proposals.
>
--
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: Context Keys Proposal Change
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> The link on the web site:
>
> http://jakarta.apache.org/avalon/excalibur/container/attributes.html
>
> Has two context keys defined an done attribute defined.
> Obviously this
> is not enough, but we need to get to the proper abstractions. Anyway,
> here are some changes that need to be performed:
>
> CONTEXT
>
> Key Type Description
> ----------- ----------------
> -------------------------------------
> avalon:home java.net.URL This is a context directory that may
> contain a bunch of files that a
> component needs to do its
> work. There
> is NO GUARANTEE that the URL is
> writable.
This change has proven itself necessary (although for the moment I can
not
remember just what the circumstances were).
-------------
Is it possible to define this in the component (the implementation) meta
so that a component can declare either avalon:home as File or as URL,
depending on need? (Backwards compatiblity.) As File would mean
writable,
as URL non-writable...
Or am I just adding complexity and semantics without a real need here?
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>