You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beehive.apache.org by "C Brett Bennett (JIRA)" <be...@incubator.apache.org> on 2004/11/30 00:59:28 UTC
[jira] Created: (BEEHIVE-100) Configurable services definition
Configurable services definition
--------------------------------
Key: BEEHIVE-100
URL: http://nagoya.apache.org/jira/browse/BEEHIVE-100
Project: Beehive
Type: New Feature
Components: Controls
Versions: V1Alpha
Reporter: C Brett Bennett
Priority: Minor
A simple scheme to allow for a container specific control container context to have a configurable set of services to be defined. This scheme can then be implemented within
various containers, including standalone ones to define the services to be provided within
those container.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (BEEHIVE-100) Configurable services definition
Posted by "Kyle Marvin (JIRA)" <be...@incubator.apache.org>.
[ http://nagoya.apache.org/jira/browse/BEEHIVE-100?page=comments#action_56034 ]
Kyle Marvin commented on BEEHIVE-100:
-------------------------------------
I've been thinking about this some... but the route I was considering wasn't so much explicit configuration as it was implicit.
What I mean by this is to have a well-defined mapping of some sort (by convention or some other mechanism) from a service interface to locate its provider. As an example, let's say the convention is that the contextual service XXX will have a provider named XXXProvider. A slightly more elegant approach might be to use an annotation on the service interface to define the associated BeanContextServiceProvider class.
The runtime can then automatically locate the provider (via classloader) and do the service provisioning. All that's required is to modify the BeanContext.getService() implementation to use the above algorithm, in addition to looking at a statically registered list.
The benefit of this is that adding new contextual services is as simple as dropping a jar into the appropriate location... no file manipulation required.
I look at external XML configuration as just a better way to build a static service list... but it's not particularly dynamic, because you have to modify local config files to see new services.
Totally agree the that current mechanism (a static list, defined in code) is not good enough.
Comments?
> Configurable services definition
> --------------------------------
>
> Key: BEEHIVE-100
> URL: http://nagoya.apache.org/jira/browse/BEEHIVE-100
> Project: Beehive
> Type: New Feature
> Components: Controls
> Versions: V1Alpha
> Reporter: C Brett Bennett
> Priority: Minor
>
> A simple scheme to allow for a container specific control container context to have a configurable set of services to be defined. This scheme can then be implemented within
> various containers, including standalone ones to define the services to be provided within
> those container.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (BEEHIVE-100) Configurable services definition
Posted by "Kyle Marvin (JIRA)" <be...@incubator.apache.org>.
[ http://nagoya.apache.org/jira/browse/BEEHIVE-100?page=comments#action_56060 ]
Kyle Marvin commented on BEEHIVE-100:
-------------------------------------
Great points, Brett.
- The enumeration of available services is problematic in an implicit classloading system, unless there is some additional mechanism above it that provides insight into a jar's contents (i.e. the contextual services inside of it)
- If the relationship between service interfaces and providers is one-to-many (i.e. there are different implementations for different contexts), then implicit loading/conventions also break down.
I'm just hoping to keep two simple cases relatively simple:
- a contextual service that has a single provider for all contexts (ex. ControlBeanContext)
- a contextual service that has a single provider but is only available in a limited set of contexts (ex. HttpRequest)
I'll withdraw concerns about a config-file based approach... if we can come up w/ a model that supports merging multiple config files (i.e. potentially ones that describe the contents of a jar), so there is no single uber-config that an end user is forced to manage, or some indirection mechanism where the uber-config can "pull" definitions from elsewhere.
We should take a look at some of the HiveMind config stuff... it actually seems fairly flexible and useful and mind cover some of these use cases.
> Configurable services definition
> --------------------------------
>
> Key: BEEHIVE-100
> URL: http://nagoya.apache.org/jira/browse/BEEHIVE-100
> Project: Beehive
> Type: New Feature
> Components: Controls
> Versions: V1Alpha
> Reporter: C Brett Bennett
> Priority: Minor
>
> A simple scheme to allow for a container specific control container context to have a configurable set of services to be defined. This scheme can then be implemented within
> various containers, including standalone ones to define the services to be provided within
> those container.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (BEEHIVE-100) Configurable services definition
Posted by "C Brett Bennett (JIRA)" <be...@incubator.apache.org>.
[ http://nagoya.apache.org/jira/browse/BEEHIVE-100?page=comments#action_56041 ]
C Brett Bennett commented on BEEHIVE-100:
-----------------------------------------
The scheme Kyle proposes shifts resposibility
from the container-context to the contextual service. Instead of the container-context
determining the services it provides via an
XML configuration file, the contextual-service
chooses its provider with the implementation specified by the provider in some static manner, e.g. XML configuration.
His goal with the scheme seems to be:
(1) Have a service implementation for a given container be implicitly loaded, e.g. using
annotation on the contextual service interface/class.
(2) Be able to package the contextual service
and it's implementation for a given container
be packaged in a single jar.
In general there are two requirements:
(1) A bean-context-services object must be able to provide an iteration of contextual-services, i.e getCurrentServiceClasses().
(2) A binding needs to be made between a contextual-service and its implementation within a given context.
The difficulty with the proposed scheme is meeting requirement (1) while being able
to 'drop' in a jar.
Comments?
> Configurable services definition
> --------------------------------
>
> Key: BEEHIVE-100
> URL: http://nagoya.apache.org/jira/browse/BEEHIVE-100
> Project: Beehive
> Type: New Feature
> Components: Controls
> Versions: V1Alpha
> Reporter: C Brett Bennett
> Priority: Minor
>
> A simple scheme to allow for a container specific control container context to have a configurable set of services to be defined. This scheme can then be implemented within
> various containers, including standalone ones to define the services to be provided within
> those container.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (BEEHIVE-100) Configurable services definition
Posted by "Kenneth Tam (JIRA)" <be...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/BEEHIVE-100?page=history ]
Kenneth Tam updated BEEHIVE-100:
--------------------------------
Assign To: Kyle Marvin
Fix Version: V1
> Configurable services definition
> --------------------------------
>
> Key: BEEHIVE-100
> URL: http://issues.apache.org/jira/browse/BEEHIVE-100
> Project: Beehive
> Type: New Feature
> Components: Controls
> Versions: V1Alpha
> Reporter: C Brett Bennett
> Assignee: Kyle Marvin
> Priority: Minor
> Fix For: V1
>
> A simple scheme to allow for a container specific control container context to have a configurable set of services to be defined. This scheme can then be implemented within
> various containers, including standalone ones to define the services to be provided within
> those container.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (BEEHIVE-100) Configurable services definition
Posted by "Kyle Marvin (JIRA)" <be...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/BEEHIVE-100?page=all ]
Kyle Marvin updated BEEHIVE-100:
--------------------------------
Fix Version: TBD
(was: V1)
This isn't going to make it into V1
> Configurable services definition
> --------------------------------
>
> Key: BEEHIVE-100
> URL: http://issues.apache.org/jira/browse/BEEHIVE-100
> Project: Beehive
> Type: New Feature
> Components: Controls
> Versions: V1Alpha
> Reporter: C Brett Bennett
> Assignee: Kyle Marvin
> Priority: Minor
> Fix For: TBD
>
> A simple scheme to allow for a container specific control container context to have a configurable set of services to be defined. This scheme can then be implemented within
> various containers, including standalone ones to define the services to be provided within
> those container.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira