On 11/26/2012 10:11 AM, Prasad GS wrote:
> Hi,
>
> We are building a product that uses the apache hadoop & hbase frameworks
> for handling some of our big data requirements. We are also using Oracle
> for our reporting requirements. We are keen to go with the OSGi way of
> bundling our software to take advantage of the remote deployment,service
> management & loosely coupled packaging features that OSGi offers.
>
> We have a few doubts in this area:
>
> 1)When it comes to our own Java apps, we now know how to create OSGi
> bundles out of them and deploy them over OSGi.But how do we handle Java
> based 3PPs that have a clustered architecture, for example HBase/Hadoop?
> We saw that Fuse Fabric has created a Hadoop (actually only HDFS not Map
> Reduce) bundle, but in general how do you go about creating bundles for
> 3PP's?
>
> 2)How do we handle non-java based 3PPs like for example Oracle. Should
> we create a OSGi bundle for it and deploy over OSGi or should we install
> these 3PP's outside of OSGi and write some monitoring scripts that are
> triggered over Fuse Fabric to track the status of these 3PP's? Are you
> aware of any best practices in this area?
>
> Regards,
> Skanda
>
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
Hi Skanda,
as nobody has responded yet to these questions I would like to share my
experiences in this area.
In a private project I developed a hybrid JavaEE/OSGi application
running on GlassFish 3.1+ with a rather hard dependency to PostgreSQL
and some other non-Java applications.
I chose to go with bringing the operating systems packaging and OSGi in
sync and establish a 1-to-1 mapping between a software package and an
OSGi bundle as this would simplify operations on test-systems as well as
production and reveal configuration errors or manual hacks rather early
due to the fully automated nature.
In my case, I am running on Debian-based systems, so the operating
system packaging part is consistent. For bridging between the actual
operating system package installation/removal/update and the respective
OSGi lifecycle events I wrote some basic GlassFish asadmin shell
commands that are being used inside the Debian package lifecycle scripts.
This way, I can have strong dependencies between all parts of the system
and detect/fix missing requirements with the help of the operating
systems package manager.
I also integrated some third-party libraries/frameworks into my
application that wasn't yet available as an OSGi bundle or that where
configured improperly for running inside a hybrid environment. In those
cases I always filed bugs against the relevant open-source projects and
often provided patches at the same time.
The thing is when packaging third-party stuff initially as an OSGi
bundle that you'll have to know how that thing works and I had quite
some projects where I had to rebuild the whole artifacts with patches.
So this can become quite some maintenance overhead, especially when the
OSGi-relevant changes are not being pushed upstream. About a year ago I
had to build ~20 projects on my own to get them running properly, but
since I always filed bugs to the relevant issue trackers and thanx to
great communities most of them now do their work out-of-the-box, which
simplifies my work when upgrading a library.
For non-Java packages I stick with the package manager that is available
at the target system, which means I don't try to OSGi-fy them. I rather
integrate OSGi inside the operating system rather the other way around,
which also means, that I have my own Debian package repositories for the
packages of my OSGi bundles.
Up to now that proved to be flexible enough and very reliable, as I
don't have to care about security fixes and package upgrades of those.
However, as I only depend on open-source software which in most cases is
already packaged, I don't have much work here. When it comes to
commercial packages that are not available as native packages I would
still do the initial extra-work of packaging them, so that you have one
place, where you can put the native package dependency management. That
also means, that I do not use "Require-Bundle" or anything similar in
the OSGi space and just stick to Java packages and versions (as with the
OSGi specifications, my Java package versions and the native package
version must not be kept in sync, as they are two different concerns).
Apart from that if you are about to support different target operating
systems (e.g. Windows, Linux, Unix, ...) the native packaging might get
to much of an overhead and it could be easier to maintain proper
installation guides to cover dependencies beyond the Java-scope.
So in the end, I cannot give you any best practices (I've never heard of
any in this area), but my experience in companies I worked in revealed,
that getting Java-stuff (be it OSGi or not) to integrate nicely into the
operating system makes administrators happy.
I hope I could be of help.
Cheers,
Ancoron
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
