Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] About CM 
Link in last post should read:

https://scm.ops4j.org/repos/ops4j/laboratory/users/bschmaus/

On 11/22/06, Benjamin Schmaus <benjamin.schmaus@xxxxxxxxx> wrote:

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