You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Teemu Kanstrén <tk...@gmail.com> on 2011/08/09 20:01:29 UTC
Fun with OSGI
Hello all,
I have used OSGI in a few projects, most recently in a research prototype
for a sensor network data collection thingy.
Overall, I think OSGI is not hugely complex and provides some useful
features. However, overall my feelings are a bit mixed. So I would like to
ask others, what are your experiences in using OSGI vs other platforms. Some
more specific experiences from my viewpoint:
-Automated updates (or support for them) are commonly mentioned as something
supported by OSGI. I see there is some basic support for this in
loading/unloading services and bundles in the standard container.
Additionally, there are things like Apache ACE that are commonly mentioned
to take it further. But I fail to see how this really helps much, the big
issue for me comes to transferring state from old services to new ones and
managing all the dependencies between the elements as change is rarely
localized. While I have needed to support updates, I find it is easier to
just deploy a complete new version and restart the software.
-Service code is separated by OSGI through different classloaders. For me
this has been really nice in keeping dependencies from spreading and forcing
me to think about component boundaries in a more focused way. But running
an OSGI container just for this seems a bit heavyweight for me. The
classloader separation also causes some big issues for me such as sharing
libraries over services, such as web-services frameworks, where managing
configuration files across services is just extra hard when the classloaders
are separated, in addition to the usual OSGI classloader issues. When
libraries are better supported, such as the Felix HTTP service with Jetty,
it seems nice but actually is a wrapper that hides the configuration options
under layers of abstraction (added complexity) that hide the more advanced
configuration options from me and makes it hard if possible at all to use
them.
-Managing the framework and my application becomes more complex as the user
has to understand the container caches, large number of directories,
libraries, configuration files, etc. Things like configuring my app to run
as a unix daemon are much more complex to manage and debug as I am not in
direct control over the platform. Errors in application startup from remote
deployments are harder since they are shown mainly in Felix and not in my
application log files.
-Using OSGI for me is a form of a local-level service abstraction (SOA). I
have basically used Java interfaces to define the "interface" of each OSGI
service. But this eliminates the navigation support my IDE in terms of
static analysis and adds, what seems to me, unnecessary abstration. This is
probably my failure in using too many interfaces but it feels to me as a
"common practice" for OSGI apps. I was also looking for some support to hook
and trace service interactions, which could justify some of this, but there
is nothing like this.
-Integration testing is difficult due to all the wiring required to get the
overall system running. In simple cases it works OK with my own
MockBundleContext, and the SOA approach makes the component composition even
cleaner in this regard. However, in more complex interactions starting the
whole container becomes a big burden for me.
Overall, the approach of SOA at local level seems great for the overall
architecture. But it seems to me currently there are just too many issues
for me, and for that reason, I would prefer a more simple approach.
Maybe I am just doing wrong or building wrong types of apps. Any other
experiences?
Thanks for your thoughts,
Teemu
Re: Fun with OSGI
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi,
I don't really like to make advertisements :-)
but since you are looking on a nice and easy way of doing Unit Tests
with OSGi did you take a look at Pax Exam [1]?
It's exactly build for this. You can create your unit test even depend
on services and Pax Exam will run it on
any kind of OSGi container if needed :-)
Regards, Achim
[1] - http://team.ops4j.org/wiki/display/paxexam/Pax+Exam
2011/8/16 Teemu Kanstrén <tk...@gmail.com>:
> Hello Peter,
>
> I think you are quite correct in your analysis. My problem is perhaps that
> I was experimenting with "too much" modularity in OSGI terms. In taking my
> application, splitting this into modules providing services with clear
> responsibilities, and composing it from these. In this case there is no real
> intent for me to ever replace one service with another. I just like the way
> it helps me avoid spaghetti et al. I shall have to look at the projects you
> link and try if they fit me better. I think perhaps without classloaders it
> is not possible to achieve some of the bigger benefits in OSGI, so maybe it
> is more of a platform (JVM) issue as well.
>
> I do not really have a problem with the container startup time. Just the
> fact that I cannot control it. If I start write a unit/integration test I
> prefer to keep it simple and run relatively fast. With OSGI (Felix) I could
> not figure how to do that simple and easy without starting a different JVM
> for the container. Well, I managed some hacks but it wasn't so easy.
>
> For the configuration, I would not call most classloader use hacks really,
> since this is mostly for me the best way to access resources bundled with
> the application jar file. Perhaps it is more a problem with the way
> frameworks and libraries are built to not provide alternative means. That
> could be hard to change, so I do not know if alternatives could be found to
> make it easier to adapt existing ones. Probably would exist if it was. I had
> a look at the bndtools site but as you say I am a control freak so probably
> not my thing.. :)
>
> Thanks for you input..
>
> Teemu
>
> 2011/8/15 Peter Kriens <pe...@aqute.biz>
>
>> I think you run in the problem that you want to have your cake and eat it
>> too. OSGi is implementing a modular system and enforces this modularity. As
>> you acknowledge, this gives a lot of advantages. Many of the problems you
>> find are then related to the problems this modularity causes (class
>> loaders!) and not having access to the implementation details.
>>
>> The problem is that if you do not enforce modularity, it will not be
>> modular. Unfortunately, in the Java world there are many popular hacks that
>> are just not modular. Trying to merge these worlds can be painful. If you
>> have proper modularity, you should not be able to navigate in your IDE
>> because an implementation could be substituted. Hiding the implementation
>> maybe makes it harder to use the special options but it eases migration and
>> makes your code more robust because it has less special dependencies.
>> Integration testing is less valuable but unit testing is crucial.
>>
>> Your pain seems to be that you have to give up control in certain areas. I
>> believe that this is an aspect of modularity/component programming and not
>> inherently OSGi. It is up to you to decide if the benefits of modularity are
>> worth the pain ... I think they are.
>>
>> That said, we're currently working on a specification that will allow the
>> OSGi service API to be used without the class loader model. See
>> http://code.google.com/p/pojosr/ or
>> http://www.osgi.org/blog/2011/04/osgi-lite.html for more. This will give
>> you the service model but it will not force you to be modular, class loader
>> hacks still work.
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>> P.S. Somehow it feels like you see the "container" as too big. It takes
>> +/-100ms to start a framework. So if you're testing you do not need to
>> create a MockBundleContext. Anyway, MOST of your code should not see a
>> BundleContext ever. Did you look at bndtools?
>>
>> On 9 aug 2011, at 20:01, Teemu Kanstrén wrote:
>>
>> > Hello all,
>> >
>> > I have used OSGI in a few projects, most recently in a research prototype
>> > for a sensor network data collection thingy.
>> >
>> > Overall, I think OSGI is not hugely complex and provides some useful
>> > features. However, overall my feelings are a bit mixed. So I would like
>> to
>> > ask others, what are your experiences in using OSGI vs other platforms.
>> Some
>> > more specific experiences from my viewpoint:
>> >
>> > -Automated updates (or support for them) are commonly mentioned as
>> something
>> > supported by OSGI. I see there is some basic support for this in
>> > loading/unloading services and bundles in the standard container.
>> > Additionally, there are things like Apache ACE that are commonly
>> mentioned
>> > to take it further. But I fail to see how this really helps much, the big
>> > issue for me comes to transferring state from old services to new ones
>> and
>> > managing all the dependencies between the elements as change is rarely
>> > localized. While I have needed to support updates, I find it is easier to
>> > just deploy a complete new version and restart the software.
>> >
>> > -Service code is separated by OSGI through different classloaders. For me
>> > this has been really nice in keeping dependencies from spreading and
>> forcing
>> > me to think about component boundaries in a more focused way. But
>> running
>> > an OSGI container just for this seems a bit heavyweight for me. The
>> > classloader separation also causes some big issues for me such as sharing
>> > libraries over services, such as web-services frameworks, where managing
>> > configuration files across services is just extra hard when the
>> classloaders
>> > are separated, in addition to the usual OSGI classloader issues. When
>> > libraries are better supported, such as the Felix HTTP service with
>> Jetty,
>> > it seems nice but actually is a wrapper that hides the configuration
>> options
>> > under layers of abstraction (added complexity) that hide the more
>> advanced
>> > configuration options from me and makes it hard if possible at all to use
>> > them.
>> >
>> > -Managing the framework and my application becomes more complex as the
>> user
>> > has to understand the container caches, large number of directories,
>> > libraries, configuration files, etc. Things like configuring my app to
>> run
>> > as a unix daemon are much more complex to manage and debug as I am not in
>> > direct control over the platform. Errors in application startup from
>> remote
>> > deployments are harder since they are shown mainly in Felix and not in my
>> > application log files.
>> >
>> > -Using OSGI for me is a form of a local-level service abstraction (SOA).
>> I
>> > have basically used Java interfaces to define the "interface" of each
>> OSGI
>> > service. But this eliminates the navigation support my IDE in terms of
>> > static analysis and adds, what seems to me, unnecessary abstration. This
>> is
>> > probably my failure in using too many interfaces but it feels to me as a
>> > "common practice" for OSGI apps. I was also looking for some support to
>> hook
>> > and trace service interactions, which could justify some of this, but
>> there
>> > is nothing like this.
>> >
>> > -Integration testing is difficult due to all the wiring required to get
>> the
>> > overall system running. In simple cases it works OK with my own
>> > MockBundleContext, and the SOA approach makes the component composition
>> even
>> > cleaner in this regard. However, in more complex interactions starting
>> the
>> > whole container becomes a big burden for me.
>> >
>> > Overall, the approach of SOA at local level seems great for the overall
>> > architecture. But it seems to me currently there are just too many issues
>> > for me, and for that reason, I would prefer a more simple approach.
>> >
>> > Maybe I am just doing wrong or building wrong types of apps. Any other
>> > experiences?
>> >
>> > Thanks for your thoughts,
>> > Teemu
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
--
--
*Achim Nierbeck*
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
Committer & Project Lead
blog <http://notizblog.nierbeck.de/>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Fun with OSGI
Posted by Teemu Kanstrén <tk...@gmail.com>.
Hello Peter,
I think you are quite correct in your analysis. My problem is perhaps that
I was experimenting with "too much" modularity in OSGI terms. In taking my
application, splitting this into modules providing services with clear
responsibilities, and composing it from these. In this case there is no real
intent for me to ever replace one service with another. I just like the way
it helps me avoid spaghetti et al. I shall have to look at the projects you
link and try if they fit me better. I think perhaps without classloaders it
is not possible to achieve some of the bigger benefits in OSGI, so maybe it
is more of a platform (JVM) issue as well.
I do not really have a problem with the container startup time. Just the
fact that I cannot control it. If I start write a unit/integration test I
prefer to keep it simple and run relatively fast. With OSGI (Felix) I could
not figure how to do that simple and easy without starting a different JVM
for the container. Well, I managed some hacks but it wasn't so easy.
For the configuration, I would not call most classloader use hacks really,
since this is mostly for me the best way to access resources bundled with
the application jar file. Perhaps it is more a problem with the way
frameworks and libraries are built to not provide alternative means. That
could be hard to change, so I do not know if alternatives could be found to
make it easier to adapt existing ones. Probably would exist if it was. I had
a look at the bndtools site but as you say I am a control freak so probably
not my thing.. :)
Thanks for you input..
Teemu
2011/8/15 Peter Kriens <pe...@aqute.biz>
> I think you run in the problem that you want to have your cake and eat it
> too. OSGi is implementing a modular system and enforces this modularity. As
> you acknowledge, this gives a lot of advantages. Many of the problems you
> find are then related to the problems this modularity causes (class
> loaders!) and not having access to the implementation details.
>
> The problem is that if you do not enforce modularity, it will not be
> modular. Unfortunately, in the Java world there are many popular hacks that
> are just not modular. Trying to merge these worlds can be painful. If you
> have proper modularity, you should not be able to navigate in your IDE
> because an implementation could be substituted. Hiding the implementation
> maybe makes it harder to use the special options but it eases migration and
> makes your code more robust because it has less special dependencies.
> Integration testing is less valuable but unit testing is crucial.
>
> Your pain seems to be that you have to give up control in certain areas. I
> believe that this is an aspect of modularity/component programming and not
> inherently OSGi. It is up to you to decide if the benefits of modularity are
> worth the pain ... I think they are.
>
> That said, we're currently working on a specification that will allow the
> OSGi service API to be used without the class loader model. See
> http://code.google.com/p/pojosr/ or
> http://www.osgi.org/blog/2011/04/osgi-lite.html for more. This will give
> you the service model but it will not force you to be modular, class loader
> hacks still work.
>
> Kind regards,
>
> Peter Kriens
>
> P.S. Somehow it feels like you see the "container" as too big. It takes
> +/-100ms to start a framework. So if you're testing you do not need to
> create a MockBundleContext. Anyway, MOST of your code should not see a
> BundleContext ever. Did you look at bndtools?
>
> On 9 aug 2011, at 20:01, Teemu Kanstrén wrote:
>
> > Hello all,
> >
> > I have used OSGI in a few projects, most recently in a research prototype
> > for a sensor network data collection thingy.
> >
> > Overall, I think OSGI is not hugely complex and provides some useful
> > features. However, overall my feelings are a bit mixed. So I would like
> to
> > ask others, what are your experiences in using OSGI vs other platforms.
> Some
> > more specific experiences from my viewpoint:
> >
> > -Automated updates (or support for them) are commonly mentioned as
> something
> > supported by OSGI. I see there is some basic support for this in
> > loading/unloading services and bundles in the standard container.
> > Additionally, there are things like Apache ACE that are commonly
> mentioned
> > to take it further. But I fail to see how this really helps much, the big
> > issue for me comes to transferring state from old services to new ones
> and
> > managing all the dependencies between the elements as change is rarely
> > localized. While I have needed to support updates, I find it is easier to
> > just deploy a complete new version and restart the software.
> >
> > -Service code is separated by OSGI through different classloaders. For me
> > this has been really nice in keeping dependencies from spreading and
> forcing
> > me to think about component boundaries in a more focused way. But
> running
> > an OSGI container just for this seems a bit heavyweight for me. The
> > classloader separation also causes some big issues for me such as sharing
> > libraries over services, such as web-services frameworks, where managing
> > configuration files across services is just extra hard when the
> classloaders
> > are separated, in addition to the usual OSGI classloader issues. When
> > libraries are better supported, such as the Felix HTTP service with
> Jetty,
> > it seems nice but actually is a wrapper that hides the configuration
> options
> > under layers of abstraction (added complexity) that hide the more
> advanced
> > configuration options from me and makes it hard if possible at all to use
> > them.
> >
> > -Managing the framework and my application becomes more complex as the
> user
> > has to understand the container caches, large number of directories,
> > libraries, configuration files, etc. Things like configuring my app to
> run
> > as a unix daemon are much more complex to manage and debug as I am not in
> > direct control over the platform. Errors in application startup from
> remote
> > deployments are harder since they are shown mainly in Felix and not in my
> > application log files.
> >
> > -Using OSGI for me is a form of a local-level service abstraction (SOA).
> I
> > have basically used Java interfaces to define the "interface" of each
> OSGI
> > service. But this eliminates the navigation support my IDE in terms of
> > static analysis and adds, what seems to me, unnecessary abstration. This
> is
> > probably my failure in using too many interfaces but it feels to me as a
> > "common practice" for OSGI apps. I was also looking for some support to
> hook
> > and trace service interactions, which could justify some of this, but
> there
> > is nothing like this.
> >
> > -Integration testing is difficult due to all the wiring required to get
> the
> > overall system running. In simple cases it works OK with my own
> > MockBundleContext, and the SOA approach makes the component composition
> even
> > cleaner in this regard. However, in more complex interactions starting
> the
> > whole container becomes a big burden for me.
> >
> > Overall, the approach of SOA at local level seems great for the overall
> > architecture. But it seems to me currently there are just too many issues
> > for me, and for that reason, I would prefer a more simple approach.
> >
> > Maybe I am just doing wrong or building wrong types of apps. Any other
> > experiences?
> >
> > Thanks for your thoughts,
> > Teemu
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Strange exception when installing a bundle
Posted by jo...@exceter.com.
I figured it out. I needed to add this to my pom,
<dependency>
<groupId>org.apache.felix</groupId>
<artifactId>org.apache.felix.framework</artifactId>
<version>3.2.2</version>
</dependency>
Quoting john.dunlap@exceter.com:
> I'm trying to install a bundle via the bundle context and I'm getting a
> strange exception.
>
> public class FileInstaller implements BundleActivator
> {
> private static final Logger LOGGER =
> LoggerFactory.getLogger(FileInstaller.class);
>
> private BundleContext bundleContext;
>
> public void start(BundleContext bundleContext) throws Exception
> {
> System.out.println("Starting system bundle");
> this.bundleContext = bundleContext;
> }
>
> public void stop(BundleContext bundleContext) throws Exception
> {
> System.out.println("Stopping system bundle");
> }
>
> public void install(File bundle) throws BundleException,
> FileNotFoundException
> {
> LOGGER.info("Attempting to install bundle(" + bundle.exists() + "):
> " + bundle.getAbsolutePath());
> bundleContext.installBundle("file://" + bundle.getAbsolutePath(),
> new FileInputStream(bundle));
> }
> }
>
> 13:39:20,187 INFO FileInstaller:39 - Attempting to install
> bundle(true):
> /home/jddunlap/hello-bundle/hello-bundle-0.0.1-SNAPSHOT.jar
> Could not create framework: org.osgi.framework.BundleException: Could
> not create bundle object.
> org.osgi.framework.BundleException: Could not create bundle object.
> at org.apache.felix.framework.Felix.installBundle(Felix.java:2650)
> at org.apache.felix.framework.Felix.installBundle(Felix.java:2501)
> at
> org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:150)
> at com.example.felix.FileInstaller.install(FileInstaller.java:40)
> at com.example.felix.FelixLauncher.run(FelixLauncher.java:69)
> at com.example.felix.FelixLauncher.main(FelixLauncher.java:30)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
> Caused by: java.lang.NoSuchMethodError:
> org.apache.felix.framework.util.VersionRange.isFloorInclusive()Z
> at
> org.apache.felix.framework.util.manifestparser.RequirementImpl.convertToFilter(RequirementImpl.java:117)
> at
> org.apache.felix.framework.util.manifestparser.RequirementImpl.<init>(RequirementImpl.java:49)
> at
> org.apache.felix.framework.util.manifestparser.ManifestParser.convertImports(ManifestParser.java:429)
> at
> org.apache.felix.framework.util.manifestparser.ManifestParser.<init>(ManifestParser.java:159)
> at org.apache.felix.framework.ModuleImpl.<init>(ModuleImpl.java:243)
> at org.apache.felix.framework.BundleImpl.createModule(BundleImpl.java:1162)
> at org.apache.felix.framework.BundleImpl.<init>(BundleImpl.java:81)
> at org.apache.felix.framework.Felix.installBundle(Felix.java:2593)
> ... 10 more
>
> Cheers!
> -John
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Strange exception when installing a bundle
Posted by jo...@exceter.com.
I'm trying to install a bundle via the bundle context and I'm getting
a strange exception.
public class FileInstaller implements BundleActivator
{
private static final Logger LOGGER =
LoggerFactory.getLogger(FileInstaller.class);
private BundleContext bundleContext;
public void start(BundleContext bundleContext) throws Exception
{
System.out.println("Starting system bundle");
this.bundleContext = bundleContext;
}
public void stop(BundleContext bundleContext) throws Exception
{
System.out.println("Stopping system bundle");
}
public void install(File bundle) throws BundleException,
FileNotFoundException
{
LOGGER.info("Attempting to install bundle(" + bundle.exists() +
"): " + bundle.getAbsolutePath());
bundleContext.installBundle("file://" + bundle.getAbsolutePath(),
new FileInputStream(bundle));
}
}
13:39:20,187 INFO FileInstaller:39 - Attempting to install
bundle(true):
/home/jddunlap/hello-bundle/hello-bundle-0.0.1-SNAPSHOT.jar
Could not create framework: org.osgi.framework.BundleException: Could
not create bundle object.
org.osgi.framework.BundleException: Could not create bundle object.
at org.apache.felix.framework.Felix.installBundle(Felix.java:2650)
at org.apache.felix.framework.Felix.installBundle(Felix.java:2501)
at
org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:150)
at com.example.felix.FileInstaller.install(FileInstaller.java:40)
at com.example.felix.FelixLauncher.run(FelixLauncher.java:69)
at com.example.felix.FelixLauncher.main(FelixLauncher.java:30)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: java.lang.NoSuchMethodError:
org.apache.felix.framework.util.VersionRange.isFloorInclusive()Z
at
org.apache.felix.framework.util.manifestparser.RequirementImpl.convertToFilter(RequirementImpl.java:117)
at
org.apache.felix.framework.util.manifestparser.RequirementImpl.<init>(RequirementImpl.java:49)
at
org.apache.felix.framework.util.manifestparser.ManifestParser.convertImports(ManifestParser.java:429)
at
org.apache.felix.framework.util.manifestparser.ManifestParser.<init>(ManifestParser.java:159)
at org.apache.felix.framework.ModuleImpl.<init>(ModuleImpl.java:243)
at org.apache.felix.framework.BundleImpl.createModule(BundleImpl.java:1162)
at org.apache.felix.framework.BundleImpl.<init>(BundleImpl.java:81)
at org.apache.felix.framework.Felix.installBundle(Felix.java:2593)
... 10 more
Cheers!
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Fun with OSGI
Posted by Peter Kriens <pe...@aqute.biz>.
I think you run in the problem that you want to have your cake and eat it too. OSGi is implementing a modular system and enforces this modularity. As you acknowledge, this gives a lot of advantages. Many of the problems you find are then related to the problems this modularity causes (class loaders!) and not having access to the implementation details.
The problem is that if you do not enforce modularity, it will not be modular. Unfortunately, in the Java world there are many popular hacks that are just not modular. Trying to merge these worlds can be painful. If you have proper modularity, you should not be able to navigate in your IDE because an implementation could be substituted. Hiding the implementation maybe makes it harder to use the special options but it eases migration and makes your code more robust because it has less special dependencies. Integration testing is less valuable but unit testing is crucial.
Your pain seems to be that you have to give up control in certain areas. I believe that this is an aspect of modularity/component programming and not inherently OSGi. It is up to you to decide if the benefits of modularity are worth the pain ... I think they are.
That said, we're currently working on a specification that will allow the OSGi service API to be used without the class loader model. See http://code.google.com/p/pojosr/ or http://www.osgi.org/blog/2011/04/osgi-lite.html for more. This will give you the service model but it will not force you to be modular, class loader hacks still work.
Kind regards,
Peter Kriens
P.S. Somehow it feels like you see the "container" as too big. It takes +/-100ms to start a framework. So if you're testing you do not need to create a MockBundleContext. Anyway, MOST of your code should not see a BundleContext ever. Did you look at bndtools?
On 9 aug 2011, at 20:01, Teemu Kanstrén wrote:
> Hello all,
>
> I have used OSGI in a few projects, most recently in a research prototype
> for a sensor network data collection thingy.
>
> Overall, I think OSGI is not hugely complex and provides some useful
> features. However, overall my feelings are a bit mixed. So I would like to
> ask others, what are your experiences in using OSGI vs other platforms. Some
> more specific experiences from my viewpoint:
>
> -Automated updates (or support for them) are commonly mentioned as something
> supported by OSGI. I see there is some basic support for this in
> loading/unloading services and bundles in the standard container.
> Additionally, there are things like Apache ACE that are commonly mentioned
> to take it further. But I fail to see how this really helps much, the big
> issue for me comes to transferring state from old services to new ones and
> managing all the dependencies between the elements as change is rarely
> localized. While I have needed to support updates, I find it is easier to
> just deploy a complete new version and restart the software.
>
> -Service code is separated by OSGI through different classloaders. For me
> this has been really nice in keeping dependencies from spreading and forcing
> me to think about component boundaries in a more focused way. But running
> an OSGI container just for this seems a bit heavyweight for me. The
> classloader separation also causes some big issues for me such as sharing
> libraries over services, such as web-services frameworks, where managing
> configuration files across services is just extra hard when the classloaders
> are separated, in addition to the usual OSGI classloader issues. When
> libraries are better supported, such as the Felix HTTP service with Jetty,
> it seems nice but actually is a wrapper that hides the configuration options
> under layers of abstraction (added complexity) that hide the more advanced
> configuration options from me and makes it hard if possible at all to use
> them.
>
> -Managing the framework and my application becomes more complex as the user
> has to understand the container caches, large number of directories,
> libraries, configuration files, etc. Things like configuring my app to run
> as a unix daemon are much more complex to manage and debug as I am not in
> direct control over the platform. Errors in application startup from remote
> deployments are harder since they are shown mainly in Felix and not in my
> application log files.
>
> -Using OSGI for me is a form of a local-level service abstraction (SOA). I
> have basically used Java interfaces to define the "interface" of each OSGI
> service. But this eliminates the navigation support my IDE in terms of
> static analysis and adds, what seems to me, unnecessary abstration. This is
> probably my failure in using too many interfaces but it feels to me as a
> "common practice" for OSGI apps. I was also looking for some support to hook
> and trace service interactions, which could justify some of this, but there
> is nothing like this.
>
> -Integration testing is difficult due to all the wiring required to get the
> overall system running. In simple cases it works OK with my own
> MockBundleContext, and the SOA approach makes the component composition even
> cleaner in this regard. However, in more complex interactions starting the
> whole container becomes a big burden for me.
>
> Overall, the approach of SOA at local level seems great for the overall
> architecture. But it seems to me currently there are just too many issues
> for me, and for that reason, I would prefer a more simple approach.
>
> Maybe I am just doing wrong or building wrong types of apps. Any other
> experiences?
>
> Thanks for your thoughts,
> Teemu
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Fun with OSGI
Posted by Donald Whytock <dw...@gmail.com>.
I tend to use basic OSGi and the Gogo interface, though one of my
command interpreters emulates Gogo commands, so that I can configure
through Jabber or email if needed. I might expand this to handle
emailing the system bundle jars to install or update.
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Unbinding method fails when deactivating service component
Posted by "Richard S. Hall" <he...@ungoverned.org>.
I think SCR may process events asynchronously to avoid deadlocks, in
which case it wouldn't be available. Just a guess...
-> richard
On 8/12/11 10:02 AM, David.Humeniuk@L-3Com.com wrote:
> I have a situation where I stop a bundle, which causes all of the
> declarative services to be deactivated. As one of the component is
> being deactivated, the SCR attempts to unbind all service references.
> One of the unbinding methods for the service uses the ServiceReference
> argument and attempts to get the service object from the reference.
> However, this doesn't work since somehow the service has already be
> unregistered.
>
> Shouldn't the unbinding method be called before the service is
> unregistered?
>
> I'm using Felix SCR 1.6.0 and Felix 3.2.2.
>
> Let me know if you need more info.
>
> David Humeniuk
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Unbinding method fails when deactivating service component
Posted by Da...@L-3Com.com.
I have a situation where I stop a bundle, which causes all of the
declarative services to be deactivated. As one of the component is
being deactivated, the SCR attempts to unbind all service references.
One of the unbinding methods for the service uses the ServiceReference
argument and attempts to get the service object from the reference.
However, this doesn't work since somehow the service has already be
unregistered.
Shouldn't the unbinding method be called before the service is
unregistered?
I'm using Felix SCR 1.6.0 and Felix 3.2.2.
Let me know if you need more info.
David Humeniuk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Fun with OSGI
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 8/13/11 15:47, Teemu Kanstrén wrote:
> Hi Richard,
>
> Could you elaborate what you mean with configuring a bundle different for
> services? In my terminology a bundle implements one or more services,
> registering those to the container. These can then "consume" other services,
> being consumers. So I do not quite understand you. Thanks for the info:)
Technically, in OSGi only bundles consume services, services do not
consume services...
Regarding configuring a bundle differently for multiple consumers, I
only was rephrasing what I thought you meant by "I was never able to
figure out how to configure shared bundles (e.g. framework libraries)
differently for different bundles using them".
A bundle can only be configured once. However, a bundle may provide one
Foo service or ten Foo services. Each Foo service technically can be
configured differently. Component models like iPOJO, DS, etc. support this.
-> richard
>
> Teemu
>
> 2011/8/12 Richard S. Hall<he...@ungoverned.org>
>
>> On 8/12/11 3:36 AM, Teemu Kanstrén wrote:
>>
>>> Hi Donald,
>>>
>>> Thanks for your experiences. I can see it being very useful if you need
>>> to
>>> have several users at the same time updating a set of commands. Did you
>>> use
>>> the basic OSGI features for this or something else on top of it?
>>>
>>> Besides the standard class-packaging issues and manifesting, another
>>> issue
>>> for me has been that I was never able to figure out how to configure
>>> shared
>>> bundles (e.g. framework libraries) differently for different bundles using
>>> them inside the same OSGI container. Because the libraries use their own
>>> classloader to load the configuration or something like that. But yes, the
>>> most common issues is the manifest thing and related issues, including the
>>> need to understand the gory details of all the issues.
>>>
>> You can't configure a bundle differently for multiple consumers in the same
>> container. However, you can do this with services.
>>
>> -> richard
>>
>>
>>
>>> I do agree that on the design front using OSGI encourages better design.
>>> That's a big plus.
>>>
>>> Teemu
>>>
>>> 2011/8/9 Donald Whytock<dw...@gmail.com>
>>>
>>> My experience with OSGi/Felix is comparatively limited compared to
>>>> some, but I think I'm making good use of its fundamental capability:
>>>> hot-swapping components.
>>>>
>>>> My app is a framework for hooking a varying number of command
>>>> interpreters to a varying number of communication components, thus
>>>> allowing multiple users connecting over different services/platforms
>>>> to enter commands to the system and possibly share the results with
>>>> other users.
>>>>
>>>> As a result, my primary need is to be able to conveniently add, update
>>>> and remove command interpreters and/or communication components at
>>>> will. Felix has been excellent for this. Because of this I've been
>>>> able to conveniently develop new parsers to provide myself with more
>>>> configuration options and debug Camel components.
>>>>
>>>> Yes, there's an issue with non-OSGi-ready libraries, but in many cases
>>>> that's just a matter of packaging them with the right manifest. The
>>>> biggest problem I've had with that is when jars depend on other jars,
>>>> sometimes four or five levels deep. But mostly this encourages me to
>>>> keep my code very lean, with minimal external dependencies, and even
>>>> with those looking for open-source equivalents to large corporate
>>>> jars.
>>>>
>>>> All told, with the required modularity thinking and the encouragement
>>>> to loose coupling, I believe working with OSGi has induced me to build
>>>> a better app.
>>>>
>>>> Don
>>>>
>>>> 2011/8/9 Teemu Kanstrén<tk...@gmail.com>:
>>>>
>>>>> Hello all,
>>>>>
>>>>> I have used OSGI in a few projects, most recently in a research
>>>>>
>>>> prototype
>>>>
>>>>> for a sensor network data collection thingy.
>>>>>
>>>>> Overall, I think OSGI is not hugely complex and provides some useful
>>>>> features. However, overall my feelings are a bit mixed. So I would like
>>>>>
>>>> to
>>>>
>>>>> ask others, what are your experiences in using OSGI vs other platforms.
>>>>>
>>>> Some
>>>>
>>>>> more specific experiences from my viewpoint:
>>>>>
>>>>> -Automated updates (or support for them) are commonly mentioned as
>>>>>
>>>> something
>>>>
>>>>> supported by OSGI. I see there is some basic support for this in
>>>>> loading/unloading services and bundles in the standard container.
>>>>> Additionally, there are things like Apache ACE that are commonly
>>>>>
>>>> mentioned
>>>>
>>>>> to take it further. But I fail to see how this really helps much, the
>>>>> big
>>>>> issue for me comes to transferring state from old services to new ones
>>>>>
>>>> and
>>>>
>>>>> managing all the dependencies between the elements as change is rarely
>>>>> localized. While I have needed to support updates, I find it is easier
>>>>> to
>>>>> just deploy a complete new version and restart the software.
>>>>>
>>>>> -Service code is separated by OSGI through different classloaders. For
>>>>> me
>>>>> this has been really nice in keeping dependencies from spreading and
>>>>>
>>>> forcing
>>>>
>>>>> me to think about component boundaries in a more focused way. But
>>>>>
>>>> running
>>>>
>>>>> an OSGI container just for this seems a bit heavyweight for me. The
>>>>> classloader separation also causes some big issues for me such as
>>>>> sharing
>>>>> libraries over services, such as web-services frameworks, where managing
>>>>> configuration files across services is just extra hard when the
>>>>>
>>>> classloaders
>>>>
>>>>> are separated, in addition to the usual OSGI classloader issues. When
>>>>> libraries are better supported, such as the Felix HTTP service with
>>>>>
>>>> Jetty,
>>>>
>>>>> it seems nice but actually is a wrapper that hides the configuration
>>>>>
>>>> options
>>>>
>>>>> under layers of abstraction (added complexity) that hide the more
>>>>>
>>>> advanced
>>>>
>>>>> configuration options from me and makes it hard if possible at all to
>>>>> use
>>>>> them.
>>>>>
>>>>> -Managing the framework and my application becomes more complex as the
>>>>>
>>>> user
>>>>
>>>>> has to understand the container caches, large number of directories,
>>>>> libraries, configuration files, etc. Things like configuring my app to
>>>>>
>>>> run
>>>>
>>>>> as a unix daemon are much more complex to manage and debug as I am not
>>>>> in
>>>>> direct control over the platform. Errors in application startup from
>>>>>
>>>> remote
>>>>
>>>>> deployments are harder since they are shown mainly in Felix and not in
>>>>> my
>>>>> application log files.
>>>>>
>>>>> -Using OSGI for me is a form of a local-level service abstraction (SOA).
>>>>>
>>>> I
>>>>
>>>>> have basically used Java interfaces to define the "interface" of each
>>>>>
>>>> OSGI
>>>>
>>>>> service. But this eliminates the navigation support my IDE in terms of
>>>>> static analysis and adds, what seems to me, unnecessary abstration. This
>>>>>
>>>> is
>>>>
>>>>> probably my failure in using too many interfaces but it feels to me as a
>>>>> "common practice" for OSGI apps. I was also looking for some support to
>>>>>
>>>> hook
>>>>
>>>>> and trace service interactions, which could justify some of this, but
>>>>>
>>>> there
>>>>
>>>>> is nothing like this.
>>>>>
>>>>> -Integration testing is difficult due to all the wiring required to get
>>>>>
>>>> the
>>>>
>>>>> overall system running. In simple cases it works OK with my own
>>>>> MockBundleContext, and the SOA approach makes the component composition
>>>>>
>>>> even
>>>>
>>>>> cleaner in this regard. However, in more complex interactions starting
>>>>>
>>>> the
>>>>
>>>>> whole container becomes a big burden for me.
>>>>>
>>>>> Overall, the approach of SOA at local level seems great for the overall
>>>>> architecture. But it seems to me currently there are just too many
>>>>> issues
>>>>> for me, and for that reason, I would prefer a more simple approach.
>>>>>
>>>>> Maybe I am just doing wrong or building wrong types of apps. Any other
>>>>> experiences?
>>>>>
>>>>> Thanks for your thoughts,
>>>>> Teemu
>>>>>
>>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Fun with OSGI
Posted by Teemu Kanstrén <tk...@gmail.com>.
Hi Richard,
Could you elaborate what you mean with configuring a bundle different for
services? In my terminology a bundle implements one or more services,
registering those to the container. These can then "consume" other services,
being consumers. So I do not quite understand you. Thanks for the info:)
Teemu
2011/8/12 Richard S. Hall <he...@ungoverned.org>
> On 8/12/11 3:36 AM, Teemu Kanstrén wrote:
>
>> Hi Donald,
>>
>> Thanks for your experiences. I can see it being very useful if you need
>> to
>> have several users at the same time updating a set of commands. Did you
>> use
>> the basic OSGI features for this or something else on top of it?
>>
>> Besides the standard class-packaging issues and manifesting, another
>> issue
>> for me has been that I was never able to figure out how to configure
>> shared
>> bundles (e.g. framework libraries) differently for different bundles using
>> them inside the same OSGI container. Because the libraries use their own
>> classloader to load the configuration or something like that. But yes, the
>> most common issues is the manifest thing and related issues, including the
>> need to understand the gory details of all the issues.
>>
>
> You can't configure a bundle differently for multiple consumers in the same
> container. However, you can do this with services.
>
> -> richard
>
>
>
>> I do agree that on the design front using OSGI encourages better design.
>> That's a big plus.
>>
>> Teemu
>>
>> 2011/8/9 Donald Whytock<dw...@gmail.com>
>>
>> My experience with OSGi/Felix is comparatively limited compared to
>>> some, but I think I'm making good use of its fundamental capability:
>>> hot-swapping components.
>>>
>>> My app is a framework for hooking a varying number of command
>>> interpreters to a varying number of communication components, thus
>>> allowing multiple users connecting over different services/platforms
>>> to enter commands to the system and possibly share the results with
>>> other users.
>>>
>>> As a result, my primary need is to be able to conveniently add, update
>>> and remove command interpreters and/or communication components at
>>> will. Felix has been excellent for this. Because of this I've been
>>> able to conveniently develop new parsers to provide myself with more
>>> configuration options and debug Camel components.
>>>
>>> Yes, there's an issue with non-OSGi-ready libraries, but in many cases
>>> that's just a matter of packaging them with the right manifest. The
>>> biggest problem I've had with that is when jars depend on other jars,
>>> sometimes four or five levels deep. But mostly this encourages me to
>>> keep my code very lean, with minimal external dependencies, and even
>>> with those looking for open-source equivalents to large corporate
>>> jars.
>>>
>>> All told, with the required modularity thinking and the encouragement
>>> to loose coupling, I believe working with OSGi has induced me to build
>>> a better app.
>>>
>>> Don
>>>
>>> 2011/8/9 Teemu Kanstrén<tk...@gmail.com>:
>>>
>>>> Hello all,
>>>>
>>>> I have used OSGI in a few projects, most recently in a research
>>>>
>>> prototype
>>>
>>>> for a sensor network data collection thingy.
>>>>
>>>> Overall, I think OSGI is not hugely complex and provides some useful
>>>> features. However, overall my feelings are a bit mixed. So I would like
>>>>
>>> to
>>>
>>>> ask others, what are your experiences in using OSGI vs other platforms.
>>>>
>>> Some
>>>
>>>> more specific experiences from my viewpoint:
>>>>
>>>> -Automated updates (or support for them) are commonly mentioned as
>>>>
>>> something
>>>
>>>> supported by OSGI. I see there is some basic support for this in
>>>> loading/unloading services and bundles in the standard container.
>>>> Additionally, there are things like Apache ACE that are commonly
>>>>
>>> mentioned
>>>
>>>> to take it further. But I fail to see how this really helps much, the
>>>> big
>>>> issue for me comes to transferring state from old services to new ones
>>>>
>>> and
>>>
>>>> managing all the dependencies between the elements as change is rarely
>>>> localized. While I have needed to support updates, I find it is easier
>>>> to
>>>> just deploy a complete new version and restart the software.
>>>>
>>>> -Service code is separated by OSGI through different classloaders. For
>>>> me
>>>> this has been really nice in keeping dependencies from spreading and
>>>>
>>> forcing
>>>
>>>> me to think about component boundaries in a more focused way. But
>>>>
>>> running
>>>
>>>> an OSGI container just for this seems a bit heavyweight for me. The
>>>> classloader separation also causes some big issues for me such as
>>>> sharing
>>>> libraries over services, such as web-services frameworks, where managing
>>>> configuration files across services is just extra hard when the
>>>>
>>> classloaders
>>>
>>>> are separated, in addition to the usual OSGI classloader issues. When
>>>> libraries are better supported, such as the Felix HTTP service with
>>>>
>>> Jetty,
>>>
>>>> it seems nice but actually is a wrapper that hides the configuration
>>>>
>>> options
>>>
>>>> under layers of abstraction (added complexity) that hide the more
>>>>
>>> advanced
>>>
>>>> configuration options from me and makes it hard if possible at all to
>>>> use
>>>> them.
>>>>
>>>> -Managing the framework and my application becomes more complex as the
>>>>
>>> user
>>>
>>>> has to understand the container caches, large number of directories,
>>>> libraries, configuration files, etc. Things like configuring my app to
>>>>
>>> run
>>>
>>>> as a unix daemon are much more complex to manage and debug as I am not
>>>> in
>>>> direct control over the platform. Errors in application startup from
>>>>
>>> remote
>>>
>>>> deployments are harder since they are shown mainly in Felix and not in
>>>> my
>>>> application log files.
>>>>
>>>> -Using OSGI for me is a form of a local-level service abstraction (SOA).
>>>>
>>> I
>>>
>>>> have basically used Java interfaces to define the "interface" of each
>>>>
>>> OSGI
>>>
>>>> service. But this eliminates the navigation support my IDE in terms of
>>>> static analysis and adds, what seems to me, unnecessary abstration. This
>>>>
>>> is
>>>
>>>> probably my failure in using too many interfaces but it feels to me as a
>>>> "common practice" for OSGI apps. I was also looking for some support to
>>>>
>>> hook
>>>
>>>> and trace service interactions, which could justify some of this, but
>>>>
>>> there
>>>
>>>> is nothing like this.
>>>>
>>>> -Integration testing is difficult due to all the wiring required to get
>>>>
>>> the
>>>
>>>> overall system running. In simple cases it works OK with my own
>>>> MockBundleContext, and the SOA approach makes the component composition
>>>>
>>> even
>>>
>>>> cleaner in this regard. However, in more complex interactions starting
>>>>
>>> the
>>>
>>>> whole container becomes a big burden for me.
>>>>
>>>> Overall, the approach of SOA at local level seems great for the overall
>>>> architecture. But it seems to me currently there are just too many
>>>> issues
>>>> for me, and for that reason, I would prefer a more simple approach.
>>>>
>>>> Maybe I am just doing wrong or building wrong types of apps. Any other
>>>> experiences?
>>>>
>>>> Thanks for your thoughts,
>>>> Teemu
>>>>
>>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Fun with OSGI
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 8/12/11 3:36 AM, Teemu Kanstrén wrote:
> Hi Donald,
>
> Thanks for your experiences. I can see it being very useful if you need to
> have several users at the same time updating a set of commands. Did you use
> the basic OSGI features for this or something else on top of it?
>
> Besides the standard class-packaging issues and manifesting, another issue
> for me has been that I was never able to figure out how to configure shared
> bundles (e.g. framework libraries) differently for different bundles using
> them inside the same OSGI container. Because the libraries use their own
> classloader to load the configuration or something like that. But yes, the
> most common issues is the manifest thing and related issues, including the
> need to understand the gory details of all the issues.
You can't configure a bundle differently for multiple consumers in the
same container. However, you can do this with services.
-> richard
>
> I do agree that on the design front using OSGI encourages better design.
> That's a big plus.
>
> Teemu
>
> 2011/8/9 Donald Whytock<dw...@gmail.com>
>
>> My experience with OSGi/Felix is comparatively limited compared to
>> some, but I think I'm making good use of its fundamental capability:
>> hot-swapping components.
>>
>> My app is a framework for hooking a varying number of command
>> interpreters to a varying number of communication components, thus
>> allowing multiple users connecting over different services/platforms
>> to enter commands to the system and possibly share the results with
>> other users.
>>
>> As a result, my primary need is to be able to conveniently add, update
>> and remove command interpreters and/or communication components at
>> will. Felix has been excellent for this. Because of this I've been
>> able to conveniently develop new parsers to provide myself with more
>> configuration options and debug Camel components.
>>
>> Yes, there's an issue with non-OSGi-ready libraries, but in many cases
>> that's just a matter of packaging them with the right manifest. The
>> biggest problem I've had with that is when jars depend on other jars,
>> sometimes four or five levels deep. But mostly this encourages me to
>> keep my code very lean, with minimal external dependencies, and even
>> with those looking for open-source equivalents to large corporate
>> jars.
>>
>> All told, with the required modularity thinking and the encouragement
>> to loose coupling, I believe working with OSGi has induced me to build
>> a better app.
>>
>> Don
>>
>> 2011/8/9 Teemu Kanstrén<tk...@gmail.com>:
>>> Hello all,
>>>
>>> I have used OSGI in a few projects, most recently in a research
>> prototype
>>> for a sensor network data collection thingy.
>>>
>>> Overall, I think OSGI is not hugely complex and provides some useful
>>> features. However, overall my feelings are a bit mixed. So I would like
>> to
>>> ask others, what are your experiences in using OSGI vs other platforms.
>> Some
>>> more specific experiences from my viewpoint:
>>>
>>> -Automated updates (or support for them) are commonly mentioned as
>> something
>>> supported by OSGI. I see there is some basic support for this in
>>> loading/unloading services and bundles in the standard container.
>>> Additionally, there are things like Apache ACE that are commonly
>> mentioned
>>> to take it further. But I fail to see how this really helps much, the big
>>> issue for me comes to transferring state from old services to new ones
>> and
>>> managing all the dependencies between the elements as change is rarely
>>> localized. While I have needed to support updates, I find it is easier to
>>> just deploy a complete new version and restart the software.
>>>
>>> -Service code is separated by OSGI through different classloaders. For me
>>> this has been really nice in keeping dependencies from spreading and
>> forcing
>>> me to think about component boundaries in a more focused way. But
>> running
>>> an OSGI container just for this seems a bit heavyweight for me. The
>>> classloader separation also causes some big issues for me such as sharing
>>> libraries over services, such as web-services frameworks, where managing
>>> configuration files across services is just extra hard when the
>> classloaders
>>> are separated, in addition to the usual OSGI classloader issues. When
>>> libraries are better supported, such as the Felix HTTP service with
>> Jetty,
>>> it seems nice but actually is a wrapper that hides the configuration
>> options
>>> under layers of abstraction (added complexity) that hide the more
>> advanced
>>> configuration options from me and makes it hard if possible at all to use
>>> them.
>>>
>>> -Managing the framework and my application becomes more complex as the
>> user
>>> has to understand the container caches, large number of directories,
>>> libraries, configuration files, etc. Things like configuring my app to
>> run
>>> as a unix daemon are much more complex to manage and debug as I am not in
>>> direct control over the platform. Errors in application startup from
>> remote
>>> deployments are harder since they are shown mainly in Felix and not in my
>>> application log files.
>>>
>>> -Using OSGI for me is a form of a local-level service abstraction (SOA).
>> I
>>> have basically used Java interfaces to define the "interface" of each
>> OSGI
>>> service. But this eliminates the navigation support my IDE in terms of
>>> static analysis and adds, what seems to me, unnecessary abstration. This
>> is
>>> probably my failure in using too many interfaces but it feels to me as a
>>> "common practice" for OSGI apps. I was also looking for some support to
>> hook
>>> and trace service interactions, which could justify some of this, but
>> there
>>> is nothing like this.
>>>
>>> -Integration testing is difficult due to all the wiring required to get
>> the
>>> overall system running. In simple cases it works OK with my own
>>> MockBundleContext, and the SOA approach makes the component composition
>> even
>>> cleaner in this regard. However, in more complex interactions starting
>> the
>>> whole container becomes a big burden for me.
>>>
>>> Overall, the approach of SOA at local level seems great for the overall
>>> architecture. But it seems to me currently there are just too many issues
>>> for me, and for that reason, I would prefer a more simple approach.
>>>
>>> Maybe I am just doing wrong or building wrong types of apps. Any other
>>> experiences?
>>>
>>> Thanks for your thoughts,
>>> Teemu
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Fun with OSGI
Posted by Teemu Kanstrén <tk...@gmail.com>.
Hi Donald,
Thanks for your experiences. I can see it being very useful if you need to
have several users at the same time updating a set of commands. Did you use
the basic OSGI features for this or something else on top of it?
Besides the standard class-packaging issues and manifesting, another issue
for me has been that I was never able to figure out how to configure shared
bundles (e.g. framework libraries) differently for different bundles using
them inside the same OSGI container. Because the libraries use their own
classloader to load the configuration or something like that. But yes, the
most common issues is the manifest thing and related issues, including the
need to understand the gory details of all the issues.
I do agree that on the design front using OSGI encourages better design.
That's a big plus.
Teemu
2011/8/9 Donald Whytock <dw...@gmail.com>
> My experience with OSGi/Felix is comparatively limited compared to
> some, but I think I'm making good use of its fundamental capability:
> hot-swapping components.
>
> My app is a framework for hooking a varying number of command
> interpreters to a varying number of communication components, thus
> allowing multiple users connecting over different services/platforms
> to enter commands to the system and possibly share the results with
> other users.
>
> As a result, my primary need is to be able to conveniently add, update
> and remove command interpreters and/or communication components at
> will. Felix has been excellent for this. Because of this I've been
> able to conveniently develop new parsers to provide myself with more
> configuration options and debug Camel components.
>
> Yes, there's an issue with non-OSGi-ready libraries, but in many cases
> that's just a matter of packaging them with the right manifest. The
> biggest problem I've had with that is when jars depend on other jars,
> sometimes four or five levels deep. But mostly this encourages me to
> keep my code very lean, with minimal external dependencies, and even
> with those looking for open-source equivalents to large corporate
> jars.
>
> All told, with the required modularity thinking and the encouragement
> to loose coupling, I believe working with OSGi has induced me to build
> a better app.
>
> Don
>
> 2011/8/9 Teemu Kanstrén <tk...@gmail.com>:
> > Hello all,
> >
> > I have used OSGI in a few projects, most recently in a research
> prototype
> > for a sensor network data collection thingy.
> >
> > Overall, I think OSGI is not hugely complex and provides some useful
> > features. However, overall my feelings are a bit mixed. So I would like
> to
> > ask others, what are your experiences in using OSGI vs other platforms.
> Some
> > more specific experiences from my viewpoint:
> >
> > -Automated updates (or support for them) are commonly mentioned as
> something
> > supported by OSGI. I see there is some basic support for this in
> > loading/unloading services and bundles in the standard container.
> > Additionally, there are things like Apache ACE that are commonly
> mentioned
> > to take it further. But I fail to see how this really helps much, the big
> > issue for me comes to transferring state from old services to new ones
> and
> > managing all the dependencies between the elements as change is rarely
> > localized. While I have needed to support updates, I find it is easier to
> > just deploy a complete new version and restart the software.
> >
> > -Service code is separated by OSGI through different classloaders. For me
> > this has been really nice in keeping dependencies from spreading and
> forcing
> > me to think about component boundaries in a more focused way. But
> running
> > an OSGI container just for this seems a bit heavyweight for me. The
> > classloader separation also causes some big issues for me such as sharing
> > libraries over services, such as web-services frameworks, where managing
> > configuration files across services is just extra hard when the
> classloaders
> > are separated, in addition to the usual OSGI classloader issues. When
> > libraries are better supported, such as the Felix HTTP service with
> Jetty,
> > it seems nice but actually is a wrapper that hides the configuration
> options
> > under layers of abstraction (added complexity) that hide the more
> advanced
> > configuration options from me and makes it hard if possible at all to use
> > them.
> >
> > -Managing the framework and my application becomes more complex as the
> user
> > has to understand the container caches, large number of directories,
> > libraries, configuration files, etc. Things like configuring my app to
> run
> > as a unix daemon are much more complex to manage and debug as I am not in
> > direct control over the platform. Errors in application startup from
> remote
> > deployments are harder since they are shown mainly in Felix and not in my
> > application log files.
> >
> > -Using OSGI for me is a form of a local-level service abstraction (SOA).
> I
> > have basically used Java interfaces to define the "interface" of each
> OSGI
> > service. But this eliminates the navigation support my IDE in terms of
> > static analysis and adds, what seems to me, unnecessary abstration. This
> is
> > probably my failure in using too many interfaces but it feels to me as a
> > "common practice" for OSGI apps. I was also looking for some support to
> hook
> > and trace service interactions, which could justify some of this, but
> there
> > is nothing like this.
> >
> > -Integration testing is difficult due to all the wiring required to get
> the
> > overall system running. In simple cases it works OK with my own
> > MockBundleContext, and the SOA approach makes the component composition
> even
> > cleaner in this regard. However, in more complex interactions starting
> the
> > whole container becomes a big burden for me.
> >
> > Overall, the approach of SOA at local level seems great for the overall
> > architecture. But it seems to me currently there are just too many issues
> > for me, and for that reason, I would prefer a more simple approach.
> >
> > Maybe I am just doing wrong or building wrong types of apps. Any other
> > experiences?
> >
> > Thanks for your thoughts,
> > Teemu
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Fun with OSGI
Posted by Donald Whytock <dw...@gmail.com>.
My experience with OSGi/Felix is comparatively limited compared to
some, but I think I'm making good use of its fundamental capability:
hot-swapping components.
My app is a framework for hooking a varying number of command
interpreters to a varying number of communication components, thus
allowing multiple users connecting over different services/platforms
to enter commands to the system and possibly share the results with
other users.
As a result, my primary need is to be able to conveniently add, update
and remove command interpreters and/or communication components at
will. Felix has been excellent for this. Because of this I've been
able to conveniently develop new parsers to provide myself with more
configuration options and debug Camel components.
Yes, there's an issue with non-OSGi-ready libraries, but in many cases
that's just a matter of packaging them with the right manifest. The
biggest problem I've had with that is when jars depend on other jars,
sometimes four or five levels deep. But mostly this encourages me to
keep my code very lean, with minimal external dependencies, and even
with those looking for open-source equivalents to large corporate
jars.
All told, with the required modularity thinking and the encouragement
to loose coupling, I believe working with OSGi has induced me to build
a better app.
Don
2011/8/9 Teemu Kanstrén <tk...@gmail.com>:
> Hello all,
>
> I have used OSGI in a few projects, most recently in a research prototype
> for a sensor network data collection thingy.
>
> Overall, I think OSGI is not hugely complex and provides some useful
> features. However, overall my feelings are a bit mixed. So I would like to
> ask others, what are your experiences in using OSGI vs other platforms. Some
> more specific experiences from my viewpoint:
>
> -Automated updates (or support for them) are commonly mentioned as something
> supported by OSGI. I see there is some basic support for this in
> loading/unloading services and bundles in the standard container.
> Additionally, there are things like Apache ACE that are commonly mentioned
> to take it further. But I fail to see how this really helps much, the big
> issue for me comes to transferring state from old services to new ones and
> managing all the dependencies between the elements as change is rarely
> localized. While I have needed to support updates, I find it is easier to
> just deploy a complete new version and restart the software.
>
> -Service code is separated by OSGI through different classloaders. For me
> this has been really nice in keeping dependencies from spreading and forcing
> me to think about component boundaries in a more focused way. But running
> an OSGI container just for this seems a bit heavyweight for me. The
> classloader separation also causes some big issues for me such as sharing
> libraries over services, such as web-services frameworks, where managing
> configuration files across services is just extra hard when the classloaders
> are separated, in addition to the usual OSGI classloader issues. When
> libraries are better supported, such as the Felix HTTP service with Jetty,
> it seems nice but actually is a wrapper that hides the configuration options
> under layers of abstraction (added complexity) that hide the more advanced
> configuration options from me and makes it hard if possible at all to use
> them.
>
> -Managing the framework and my application becomes more complex as the user
> has to understand the container caches, large number of directories,
> libraries, configuration files, etc. Things like configuring my app to run
> as a unix daemon are much more complex to manage and debug as I am not in
> direct control over the platform. Errors in application startup from remote
> deployments are harder since they are shown mainly in Felix and not in my
> application log files.
>
> -Using OSGI for me is a form of a local-level service abstraction (SOA). I
> have basically used Java interfaces to define the "interface" of each OSGI
> service. But this eliminates the navigation support my IDE in terms of
> static analysis and adds, what seems to me, unnecessary abstration. This is
> probably my failure in using too many interfaces but it feels to me as a
> "common practice" for OSGI apps. I was also looking for some support to hook
> and trace service interactions, which could justify some of this, but there
> is nothing like this.
>
> -Integration testing is difficult due to all the wiring required to get the
> overall system running. In simple cases it works OK with my own
> MockBundleContext, and the SOA approach makes the component composition even
> cleaner in this regard. However, in more complex interactions starting the
> whole container becomes a big burden for me.
>
> Overall, the approach of SOA at local level seems great for the overall
> architecture. But it seems to me currently there are just too many issues
> for me, and for that reason, I would prefer a more simple approach.
>
> Maybe I am just doing wrong or building wrong types of apps. Any other
> experiences?
>
> Thanks for your thoughts,
> Teemu
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org