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 2003/03/18 06:21:33 UTC
Minimal set of component attributes?
I have some rudimentary support for using attributes to represent
components and their roles. The core mechanisms in Fortress have
not changed, but I am adding a new RoleManager that can read a
resolve components from several different jars automatically.
It will be used in my GUIApp system--but I want to put it in Fortress
before we release as well. I want to mark the services and components
with a minimal set of attributes--which will get our users used to
added functionality in Merlin and Phoenix.
I can think of the following *core* attributes:
@avalon.service -- Required for marking role interfaces.
@avalon.component -- Superfluous because I can cull all
the implementations of a service quite
easily. Used in Merlin and Phoenix though.
@avalon.scope -- Used to represent the scope of the component,
and consequently the lifestyle. Values are
"container", "thread", and "request"
Non standard container specific attributes would be:
@fortress.configname -- The short name used for component configuration.
I would like to see this as an official Avalon
attribute because I feel strongly that the
simple name of a component's configuration
element should reflect a *type* (implementation)
and not an instance. I am not willing to
fight a long battle on it.
@fortress.handler -- The fully qualified name of the component handler.
Used to access new variants or non-prefered
handlers. The main three can be accessed via
avalon.scope.
Two of these are already a done deal, the only two to get feedback
on are @avalon.scope and @avalon.configname.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Minimal set of component attributes?
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 19 Mar 2003 01:08, Berin Loritsch wrote:
> This late breaking stuff does not use Commons Attribute. It imposes a
> packaging scheme that is administrated by ANT tasks--much like Phoenix
> does. I adapted the code from Phoenix's MetaGenerateTask (using QDox)
> to collect the information.
kool.
--
Cheers,
Peter Donald
------------------------------------------------
"No. Try not. Do. Or do not. There is no try."
-- Yoda
------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Minimal set of component attributes?
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Peter Donald wrote:
>
>> Hi,
>>
>> On Tue, 18 Mar 2003 23:48, Berin Loritsch wrote:
>>
>>> As to how it is to work with it, could you provide some feedback for
>>> us? Is it something you wrestle with, or does it just work?
>>
>>
>>
>> I outlined a bunch of issues with it last time. However the biggest
>> issue is that is not being maintained. Maybe this late breaking stuff
>> should be put off till post release of fortress 1.0 and then you can
>> spend as much as you want experimenting without harming our users or
>> making it difficult to migrate.
>
>
> This late breaking stuff does not use Commons Attribute. It imposes a
> packaging scheme that is administrated by ANT tasks--much like Phoenix
> does. I adapted the code from Phoenix's MetaGenerateTask (using QDox)
> to collect the information.
>
> From the user perspective, all they know is that they need to use the
> ANT tasks to package the components, and add a couple notes for people
> who want to generate new components (done in Cocoon).
>
> The docs would clearly state that while the @avalon prefixed javadoc
> tags would be used by future containers, the @fortress prefixed ones
> are specific to Fortress.
>
> The important thing is to provide *source* compatibility at this level.
> Before the Merlin release, I want to provide *package* compatibility.
>
> Right now both Fortress and ECM are sooo different from the rest of
> the Avalon containers that it is going to impose difficulties in
> migrating to other containers.
>
> This step brings Fortress a bit closer (though less featured) to the
> other containers. In essense, once the developer makes the step to
> Fortress, it becomes *alot* easier to swap out the container and
> make it work in other environments. The only thing that would need
> to be done to the components is *possibly* add more meta information.
> The tags already used would still be present in the future.
Berin:
I think you have hit the nail on the head. The key point is that there
is a substantive difference today between Fortress 1.0 and the next step
- and the key benefit of what your describing is the potential to
establish a minimal initial context that will facilitate change. If we
only have the name/shorthand, lifestyle, and service declarations, it's
putting the idea into people minds. Looking forward it means evolution
instead of revolution.
Two hours ago I was wavering - now I can see the rationalization that
makes sense in terms of where we are heading.
>
> I am willing to push Fortress to Phase III of the Excalibur releases
> so we can straighten out this issue.
+1
Let's make it happen.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Minimal set of component attributes?
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> Hi,
>
> On Tue, 18 Mar 2003 23:48, Berin Loritsch wrote:
>
>>As to how it is to work with it, could you provide some feedback for
>>us? Is it something you wrestle with, or does it just work?
>
>
> I outlined a bunch of issues with it last time. However the biggest issue is
> that is not being maintained. Maybe this late breaking stuff should be put
> off till post release of fortress 1.0 and then you can spend as much as you
> want experimenting without harming our users or making it difficult to
> migrate.
This late breaking stuff does not use Commons Attribute. It imposes a
packaging scheme that is administrated by ANT tasks--much like Phoenix
does. I adapted the code from Phoenix's MetaGenerateTask (using QDox)
to collect the information.
From the user perspective, all they know is that they need to use the
ANT tasks to package the components, and add a couple notes for people
who want to generate new components (done in Cocoon).
The docs would clearly state that while the @avalon prefixed javadoc
tags would be used by future containers, the @fortress prefixed ones
are specific to Fortress.
The important thing is to provide *source* compatibility at this level.
Before the Merlin release, I want to provide *package* compatibility.
Right now both Fortress and ECM are sooo different from the rest of
the Avalon containers that it is going to impose difficulties in
migrating to other containers.
This step brings Fortress a bit closer (though less featured) to the
other containers. In essense, once the developer makes the step to
Fortress, it becomes *alot* easier to swap out the container and
make it work in other environments. The only thing that would need
to be done to the components is *possibly* add more meta information.
The tags already used would still be present in the future.
I am willing to push Fortress to Phase III of the Excalibur releases
so we can straighten out this issue.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Minimal set of component attributes?
Posted by Peter Donald <pe...@realityforge.org>.
Hi,
On Tue, 18 Mar 2003 23:48, Berin Loritsch wrote:
> As to how it is to work with it, could you provide some feedback for
> us? Is it something you wrestle with, or does it just work?
I outlined a bunch of issues with it last time. However the biggest issue is
that is not being maintained. Maybe this late breaking stuff should be put
off till post release of fortress 1.0 and then you can spend as much as you
want experimenting without harming our users or making it difficult to
migrate.
--
Cheers,
Peter Donald
-----------------------------------------------------
When a stupid man is doing something he's ashamed of,
he always declares that it is his duty.
George Bernard Shaw
-----------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Minimal set of component attributes?
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Paul Hammant wrote:
> Berin,
>
> AltRMI is using the Attributes framework from Commons. What do you
> think we should do. Have our own comp or use commons ?
Definitely use commons. Let's not even get into this maintenance
work.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Minimal set of component attributes?
Posted by Berin Loritsch <bl...@apache.org>.
Paul Hammant wrote:
> Berin,
>
> AltRMI is using the Attributes framework from Commons. What do you think
> we should do. Have our own comp or use commons ?
I personally want to get out of the library maintenance business.
I through together something braindead simple that works for Fortress'
case. The only thing that I don't like about the Attributes framework
is that I don't believe it has been officially released yet.
As to how it is to work with it, could you provide some feedback for
us? Is it something you wrestle with, or does it just work?
Keep in mind I throught together the implementation last night w/o
connecting to the net to download Attributes (I thought about it
though).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Minimal set of component attributes?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote, On 18/03/2003 8.15:
> Berin,
>
> AltRMI is using the Attributes framework from Commons. What do you think
> we should do. Have our own comp or use commons ?
It would be really cool to use the commons version :-)
I had a look at it and it seems simple and right2thePoint.
There is also the clazz project that could do it, but it seems to 'big'
for just this feature. Not sure, just an impression.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Minimal set of component attributes?
Posted by Paul Hammant <Pa...@yahoo.com>.
Berin,
AltRMI is using the Attributes framework from Commons. What do you think
we should do. Have our own comp or use commons ?
- Paul
> I have some rudimentary support for using attributes to represent
> components and their roles. The core mechanisms in Fortress have
> not changed, but I am adding a new RoleManager that can read a
> resolve components from several different jars automatically.
>
> It will be used in my GUIApp system--but I want to put it in Fortress
> before we release as well. I want to mark the services and components
> with a minimal set of attributes--which will get our users used to
> added functionality in Merlin and Phoenix.
>
> I can think of the following *core* attributes:
>
> @avalon.service -- Required for marking role interfaces.
>
> @avalon.component -- Superfluous because I can cull all
> the implementations of a service quite
> easily. Used in Merlin and Phoenix though.
>
> @avalon.scope -- Used to represent the scope of the component,
> and consequently the lifestyle. Values are
> "container", "thread", and "request"
>
>
> Non standard container specific attributes would be:
>
> @fortress.configname -- The short name used for component configuration.
> I would like to see this as an official Avalon
> attribute because I feel strongly that the
> simple name of a component's configuration
> element should reflect a *type* (implementation)
> and not an instance. I am not willing to
> fight a long battle on it.
>
> @fortress.handler -- The fully qualified name of the component handler.
> Used to access new variants or non-prefered
> handlers. The main three can be accessed via
> avalon.scope.
>
>
> Two of these are already a done deal, the only two to get feedback
> on are @avalon.scope and @avalon.configname.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Minimal set of component attributes?
Posted by Stefano Mazzocchi <st...@apache.org>.
Berin Loritsch wrote:
> Stefano Mazzocchi wrote:
>
>> Berin Loritsch wrote:
>>
>>> I have some rudimentary support for using attributes to represent
>>> components and their roles. The core mechanisms in Fortress have
>>> not changed, but I am adding a new RoleManager that can read a
>>> resolve components from several different jars automatically.
>>
>>
>>
>> do you envision any chance that fortress could mandate the use of a
>> namespaced (not-javadoc) comment tag for those attributes?
>>
>> Just Curious.
>
>
> Problem is time. I personally do not want to write a parser to read
> all the source code files and find the new DocTags in the component.
> I also have the oppinion that the proposed comment styles are ugly,
> though not nearly as ugly as the C# comment tags.
>
> Its also a question of what's easy to tool? We have tools already
> available to work with JavaDoc tags which makes things really easy to
> implement. We also have the advantage that Java developers are *used*
> to JavaDoc tags. It may not be the most elegant from your standpoint,
> but it does work. (We all have things we prefer from an elegance
> point of view).
No problem, just curious of what others thought about this.
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Minimal set of component attributes?
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
> Berin Loritsch wrote:
>
>> I have some rudimentary support for using attributes to represent
>> components and their roles. The core mechanisms in Fortress have
>> not changed, but I am adding a new RoleManager that can read a
>> resolve components from several different jars automatically.
>
>
> do you envision any chance that fortress could mandate the use of a
> namespaced (not-javadoc) comment tag for those attributes?
>
> Just Curious.
Problem is time. I personally do not want to write a parser to read
all the source code files and find the new DocTags in the component.
I also have the oppinion that the proposed comment styles are ugly,
though not nearly as ugly as the C# comment tags.
Its also a question of what's easy to tool? We have tools already
available to work with JavaDoc tags which makes things really easy to
implement. We also have the advantage that Java developers are *used*
to JavaDoc tags. It may not be the most elegant from your standpoint,
but it does work. (We all have things we prefer from an elegance
point of view).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Minimal set of component attributes?
Posted by Stefano Mazzocchi <st...@apache.org>.
Berin Loritsch wrote:
> I have some rudimentary support for using attributes to represent
> components and their roles. The core mechanisms in Fortress have
> not changed, but I am adding a new RoleManager that can read a
> resolve components from several different jars automatically.
do you envision any chance that fortress could mandate the use of a
namespaced (not-javadoc) comment tag for those attributes?
Just Curious.
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Minimal set of component attributes?
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>>>
>>>
>>> This one. It is much easier to mark an interface with a flag
>>> than to rely on the fact that I have a memory like a seive.
>>
>>
>>
>>
>> LOL :-)
>>
>> Know what you mean. However, it's problamatic in that it locks you
>> into a model where the interface can only be a work interface and
>> cannot be applied as a internal interface. I've thought about the
>> same approach with respect to lifecycle stages in Merlin and reached
>> the conclusion that its too restrictive - ended up focussing on
>> explicity declaring the published services, lifecycle extensions,
>> etc. in the component. But keep in mind that what I have been doing
>> is still real early.
>
>
>
>
> Who said you can't have it both ways? I have seen nothing to restrict
> us to forcing only one way on the attribute declarations.
If you use the same tag to declare that an interface is a service, and
to declare that a class is exposting a service, then you lose the
ability to verify placement relative to context. I agree that it would
be feasible to have both, but they should be different statements - for
example.:
@avalon:service.defintion // marks an interface as a service
@avalon:service org.apache.playground.Demo // this component class
exports the Demo interface
This enables you to verify that a tag is within a valid context - i.e.
avalon:service.defintion would be valid in the header of an interface
whereas avalon:service would be valid i the header of a class.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Minimal set of component attributes?
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>>
>>
>> This one. It is much easier to mark an interface with a flag
>> than to rely on the fact that I have a memory like a seive.
>
>
>
> LOL :-)
>
> Know what you mean. However, it's problamatic in that it locks you into
> a model where the interface can only be a work interface and cannot be
> applied as a internal interface. I've thought about the same approach
> with respect to lifecycle stages in Merlin and reached the conclusion
> that its too restrictive - ended up focussing on explicity declaring the
> published services, lifecycle extensions, etc. in the component. But
> keep in mind that what I have been doing is still real early.
Who said you can't have it both ways? I have seen nothing to restrict
us to forcing only one way on the attribute declarations.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Minimal set of component attributes?
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>>
>> Berin Loritsch wrote:
>>
>>> I have some rudimentary support for using attributes to represent
>>> components and their roles. The core mechanisms in Fortress have
>>> not changed, but I am adding a new RoleManager that can read a
>>> resolve components from several different jars automatically.
>>>
>>> It will be used in my GUIApp system--but I want to put it in Fortress
>>> before we release as well. I want to mark the services and components
>>> with a minimal set of attributes--which will get our users used to
>>> added functionality in Merlin and Phoenix.
>>>
>>> I can think of the following *core* attributes:
>>>
>>> @avalon.service -- Required for marking role interfaces.
>>
>>
>>
>>
>> Are you using this as a marker attribute in an interface soruce or a
>> attribute of a component class?
>>
>> i.e. @avalon.service <---- this is a work interface
>
>
> This one. It is much easier to mark an interface with a flag
> than to rely on the fact that I have a memory like a seive.
LOL :-)
Know what you mean. However, it's problamatic in that it locks you into
a model where the interface can only be a work interface and cannot be
applied as a internal interface. I've thought about the same approach
with respect to lifecycle stages in Merlin and reached the conclusion
that its too restrictive - ended up focussing on explicity declaring the
published services, lifecycle extensions, etc. in the component. But
keep in mind that what I have been doing is still real early.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Minimal set of component attributes?
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>
> Berin Loritsch wrote:
>
>> I have some rudimentary support for using attributes to represent
>> components and their roles. The core mechanisms in Fortress have
>> not changed, but I am adding a new RoleManager that can read a
>> resolve components from several different jars automatically.
>>
>> It will be used in my GUIApp system--but I want to put it in Fortress
>> before we release as well. I want to mark the services and components
>> with a minimal set of attributes--which will get our users used to
>> added functionality in Merlin and Phoenix.
>>
>> I can think of the following *core* attributes:
>>
>> @avalon.service -- Required for marking role interfaces.
>
>
>
> Are you using this as a marker attribute in an interface soruce or a
> attribute of a component class?
>
> i.e. @avalon.service <---- this is a work interface
This one. It is much easier to mark an interface with a flag
than to rely on the fact that I have a memory like a seive.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Minimal set of component attributes?
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> I have some rudimentary support for using attributes to represent
> components and their roles. The core mechanisms in Fortress have
> not changed, but I am adding a new RoleManager that can read a
> resolve components from several different jars automatically.
>
> It will be used in my GUIApp system--but I want to put it in Fortress
> before we release as well. I want to mark the services and components
> with a minimal set of attributes--which will get our users used to
> added functionality in Merlin and Phoenix.
>
> I can think of the following *core* attributes:
>
> @avalon.service -- Required for marking role interfaces.
Are you using this as a marker attribute in an interface soruce or a
attribute of a component class?
i.e. @avalon.service <---- this is a work interface
or @avalon.service xxx.yyy.MyInterface <--- this class exposes this
service as a work interface
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Minimal set of component attributes?
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Tue, 18 Mar 2003 16:21, Berin Loritsch wrote:
>
>>I can think of the following *core* attributes:
>
>
> see avalon-sandbox/info/src/xdocs/xdoclet.xml for what I consider core
> attributes.
>
>
>>@avalon.service -- Required for marking role interfaces.
>
>
> I thought we already decided to use the term "service" to refer to the work
> interfaces that a component provides other components. It would be better to
> use @avalon.role or @avalon.interface as marker for work interface.
**As long as it is considered a _standard_ name and supported accross
**_all_ our containers: +1
>>@avalon.scope -- Used to represent the scope of the component,
>> and consequently the lifestyle. Values are
>> "container", "thread", and "request"
>
>
> Not common across avalon and I can think of several more "scopes". So this is
> largely container specific and should be in the fortress namespace.
True. I was thinking these would be the "core" set. Additional scopes
like "session" scope or "application" scope or "block" scope are
specific to the containers that use them.
The question is how would you prefer to express component lifestyle?
I would like to get this resolved so that as the user migrates from
Fortress to Merlin to Phoenix they don't have to do a global replace
on all their source files. Set the attribute once, and it will be
automatically used in all the containers.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Minimal set of component attributes?
Posted by Stephen McConnell <mc...@apache.org>.
dvillevalois@phpapp.org wrote:
>>not unless we want to violate the javadoc spec. It identifies "." as the
>>name space separator.
>>
>>And there is no reason why "." could not be used for that very purpose
>>aswell.
>>
>>
>
>I think the . namespace separator is meant to follow java namespaces. Said in
>another manner, this means, for your purpose, that you must say:
>
>@org.apache.avalon.service
>
>and not
>
>@avalon.service
>
>Does this seem correct to you ??
>
Hi Didier:
The javadoc spec *states* that the javadoc phrase is an '@' character
following by a string representing a key followed by a value terminated
by a line break. The references in the spec concerning namespacing are
suggestions only with the reference to the fact that Sun does not and
will not include a period keys it defines. In practice there is no
namespace notion (i.e. no formal way to partition tag relative to a
particular domain) which means you have to devise your own. Given the
function of a javadoc comment - basically a tagged single line of text,
you really want to keep the key as short as possible for reasons of
legibility (simply because you can't throw a line break in there) which
means the @org.apache.avalon.service becomes overly verbose once you
start using values as well. So it's a compromise.
The namespace separation issue can be whatever you like but there are
problems you can encounter. A '.' character is what the javadoc tool
will check for when processing non-standard tags and is "required" if
you want to avoid javadoc warning warnings (unless you use Taglets which
bypass the issue). The ':' character means more to me but at the end of
the day it's nothing to get excited about.
What I find more interesting is using stuff like qdox for meta data
generation in combination with Taglets so we get coverage in terms of
automated meta info generation combined with the potential to leverage
the same information in better component documentation under the
generated javadoc.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Minimal set of component attributes?
Posted by dv...@phpapp.org.
> not unless we want to violate the javadoc spec. It identifies "." as the
> name
> space separator.
>
> And there is no reason why "." could not be used for that very purpose
> aswell.
I think the . namespace separator is meant to follow java namespaces. Said in
another manner, this means, for your purpose, that you must say:
@org.apache.avalon.service
and not
@avalon.service
Does this seem correct to you ?? This is why i think we should use : in order to
say that avalon: is org.apache.avalon.
However this is not something very important... :)
A+. Didier.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Minimal set of component attributes?
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 18 Mar 2003 21:10, dvillevalois@phpapp.org wrote:
> Quoting Peter Donald <pe...@realityforge.org>:
> > > @avalon.service -- Required for marking role interfaces.
>
> Could we use namespaced attributes as proposed Stephen ???
not unless we want to violate the javadoc spec. It identifies "." as the name
space separator.
> like avalon:attribute...
> This seems to become common ground for all those that uses attributes in
> other projects.
And there is no reason why "." could not be used for that very purpose aswell.
--
Cheers,
Peter Donald
*------------------------------------------------*
| Trying is the first step to failure. |
| So never try, Lisa - Homer Jay Simpson |
*------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Minimal set of component attributes?
Posted by dv...@phpapp.org.
Quoting Peter Donald <pe...@realityforge.org>:
> > @avalon.service -- Required for marking role interfaces.
Could we use namespaced attributes as proposed Stephen ???
like avalon:attribute...
This seems to become common ground for all those that uses attributes in other
projects.
A+. Didier.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Minimal set of component attributes?
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 18 Mar 2003 16:21, Berin Loritsch wrote:
> I can think of the following *core* attributes:
see avalon-sandbox/info/src/xdocs/xdoclet.xml for what I consider core
attributes.
> @avalon.service -- Required for marking role interfaces.
I thought we already decided to use the term "service" to refer to the work
interfaces that a component provides other components. It would be better to
use @avalon.role or @avalon.interface as marker for work interface.
> @avalon.scope -- Used to represent the scope of the component,
> and consequently the lifestyle. Values are
> "container", "thread", and "request"
Not common across avalon and I can think of several more "scopes". So this is
largely container specific and should be in the fortress namespace.
--
Cheers,
Peter Donald
-------------------------------------------------------
To fight and conquer in all your battles is not supreme
excellence; supreme excellence consists in breaking the
enemy's resistance without fighting. - Sun Tzu, 300 B.C.
-------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Minimal set of component attributes?
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> @avalon.scope -- Used to represent the scope of the component,
> and consequently the lifestyle. Values are
> "container", "thread", and "request"
I was wondering if it isn't better to explicitly specify what the
scope will result in, rather than trying to abstract away from it.
Thus, we'd have "singleton" instead of "threadsafe"/"container",
"pooled" instead of "request".
It seems like everyone equates ThreadSafe -> Singleton anyway, and
honestly this abstraction isn't really giving us very much.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org