Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] About CM

I agree with Neil in the sense that ConfigurationAdmin can be used
reasonably for providing configuration data for enterprise apps.

The ConfigurationAdmin service is fairly low-level, as Neil said it
doesn't deal with external aspects nor does it provide UI, but these
things can be written on top of ConfigurationAdmin.

I've done a good deal of work on this lately.  The following post may
be of interest to you.

http://article.gmane.org/gmane.comp.java.ops4j.general/1193/match=managedservicefactory

I'm planning on committing some code (hopefully later today) to the
ops4j laboratory that allows ManagedServices and
ManagedServiceFactorys to be configured from an external (outside of
the bundle) location via java properties files. It would also be
possible to provide configuration from relational DB tables, for
example.

On a different note, in the DeclarativeServices component above, you
do not need to specify a service.pid as a component property.  The
name of the component *is* the service.pid.  DeclarativeServices will
automatically merge configuration data for that pid with the
component's component properties.

From DS spec:

If there exists a Configuration with a PID equal to
the component name, then component configurations will obtain addi-
tional component properties from Configuration Admin. This is the
ManagedService situation.

DS is also supposed to support the ManagedServiceFactory scenario, but
there is currently a bug in the equinox impl of DS that prevents this
case from being handled correctly.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=163705

HTH

- Ben

On 11/22/06, Neil Bartlett <njbartlett@xxxxxxxxx> wrote:
Jerry,

You're right in one regard: a single Configuration object in the CM store
can only be bound by one ManagedService instance. However, Config Admin is
not an administration interface. It describes the internal workings of
configuration in OSGi, along with a programmatic API for accessing and
modifying the configuration, but it does not deal with external aspects at
all and it does not offer any UI.

I think it is unlikely that the Configuration objects in the CM store will
have a direct mapping to the conceptual properties that an administrator
would configure. Nobody really knows what the administration interface for
an "enterprise" OSGi application will look like at this point, and I guess
that one of the things the EEG plan to do is to come up with some guidance
in this area.

In my opinion, most adminstrators would prefer the familiarity of good old
.properties files (or perhaps XML or JSON formats), and so I think
management agents will appear that support a mapping from external config
files onto the Configuration store (and back). Also JMX has some momentum,
since there is a lot of tool support for it, and there are some management
agents already available that offer a mapping from JMX to Config Admin (eg
JMood). There is no reason why these mappings would need to be one-to-one.

In summary: I think that Config Admin IS suitable for enterprise apps, but
it's not the whole solution.

Regards,
Neil

> I'm so sorry for my poor knowledge about the CM implemention of Equinox.
>
> In equinox,We can set service's "service.bundleLocation" value to
> null,then we can use ConfigurationAdmin to manage other bundle's
> service properties without service's bundleLocation.
> Code like this:
> <component name="PortComponent">
>       <implementation class="com.terdon.spike.port.PortService"/>
>       <property name="service.pid" value="com.terdon.port"/>
>       <property name="service.bundleLocation" value="null"/>
>       <service>
>               <provide interface="org.osgi.service.cm.ManagedService"/>
>       </service>
> </component>
> then ManageBundle can use this to manage the configuration:
> Configuration configuration=admin.getConfiguration("com.terdon.port",
> null);
>
> But about how to share properties in two & more bundles,I don't know.
> can somebody tell me how to do?
>
> 2006/11/22, jerry lin <bluedavy@xxxxxxxxx>:
>> I want to know how do u can make two service share one configuration.
>>
>> 2006/11/22, Benjamin Schmaus <benjamin.schmaus@xxxxxxxxx>:
>> > >      The core key element of CM is formed by Service.PID &
>> > > BundleLocation,according to this,configuration only can be got with
>> > > this two element
>> >
>> > You can also access Configuration objects by using
>> > ConfigurationAdmin.listConfigurations or you can use a
>> > ConfigurationListener.  There is no reason that a given ManagedService
>> > can't provide configuration data to multiple client bundles.
>> >
>> > - Ben
>> >
>> > On 11/21/06, jerry lin <bluedavy@xxxxxxxxx> wrote:
>> > > hi,folks!
>> > >
>> > >      I used CM to realize system's configuration,I think the design
>> > > of CM is not very suitable for enterprise application.
>> > >      why?
>> > >      The core key element of CM is formed by Service.PID &
>> > > BundleLocation,according to this,configuration only can be got with
>> > > this two element,but in enterprise application,we often have common
>> > > configuration,just like one port configuration need to be used in
>> two
>> > > bundles,with CM,we must managed this common configuration separate
>> in
>> > > two bundles.From this point,I think CM not suitable for application
>> > > level.
>> > >       Because CM used Service.PID & Bundle Location as key,when I
>> > > moved my bundle to other path,its configuration lost,and cann't be
>> set
>> > > again,is this the bug of equinox or the question of CM?
>> > >       I think CM need do something to make it more useful for
>> > > application level configuration.
>> > >
>> > > --
>> > > =============================
>> > > |     BlueDavy                                     |
>> > > |     MSN: BlueDavy@xxxxxxxxxxx       |
>> > > =============================
>> > > _______________________________________________
>> > > equinox-dev mailing list
>> > > equinox-dev@xxxxxxxxxxx
>> > > https://dev.eclipse.org/mailman/listinfo/equinox-dev
>> > >
>> > _______________________________________________
>> > equinox-dev mailing list
>> > equinox-dev@xxxxxxxxxxx
>> > https://dev.eclipse.org/mailman/listinfo/equinox-dev
>> >
>>
>>
>> --
>> =============================
>> |     www.blogjava.net/bluedavy             |
>> =============================
>>
>
>
> --
> =============================
> |     www.blogjava.net/bluedavy             |
> =============================
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>


_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev



Back to the top