Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] About CM 
This may be of interest to you.

http://lists.ops4j.org/pipermail/general/2006q4/001233.html

On 11/22/06, jerry lin <bluedavy@xxxxxxxxx> wrote:

Many thanks to Benjamin and Neil.
Yours reply help me so much.

2006/11/22, Benjamin Schmaus <benjamin.schmaus@xxxxxxxxx>:
> 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
> >
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>


--
=============================
|     www.blogjava.net/bluedavy             |
=============================
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Back to the top