Greetings,
as some of you may know, I have been trying to import the Quartz
<https://quartz-scheduler.org/>library into my vanilla OSGi project.
Importing third-party dependencies into an OSGi container is usually a
daunting task time consuming, most of the times not even worth it hours
after starting it.
This problem is so severe, that I was asked to post in my blog the
solutions I've found so far to work around this issue
(http://web.ist.utl.pt/ist162500/?cat=2 - sorry for the messy images and
ugly UI, I am working on a new server to host my blog).
Well, so far no luck on importing quartz... Both original quartz library
bundle and amdatu bundle
<http://www.amdatu.org/components/scheduling.html> import even more
dependencies as mandatory:
(Amdatu)
*Import-Package:* com.mchange.v2.c3p0;resolution:=optional,
javax.ejb;resolution:=optional,
javax.mail;resolution:=optional,
javax.mail.internet;resolution:=optional,
javax.jms;resolution:=optional,
javax.rmi;resolution:=optional,
javax.naming;resolution:=optional,
*javax.management,**
**javax.management.openmbean,**
**javax.servlet,**
**javax.servlet.http,**
**javax.sql,**
**javax.transaction,**
**javax.xml.bind,**
**javax.xml.namespace,**
**javax.xml.parsers,**
**javax.xml.xpath,*
org.amdatu.scheduling.annotations;version="[1.0,2)",
org.amdatu.scheduling.annotations.timeinterval;version="[1.0,2)",
org.apache.felix.dm;version="[4.0,5)",
org.osgi.framework;version="[1.6,2)",
org.osgi.service.log;version="[1.3,2)",
*org.w3c.dom,**
**org.xml.sax*
(Quartz terracotta)
*Import-Package:* *com.mchange.v2.c3p0,*
commonj.work;resolution:=optional,
javax.ejb;resolution:=optional,
javax.jms;resolution:=optional,
javax.mail;resolution:=optional,
javax.mail.internet;resolution:=optional,
*javax.management,**
**javax.management.openmbean,**
**javax.naming,*
javax.servlet;resolution:=optional,
javax.servlet.http;resolution:=optional,
javax.sql;resolution:=optional,
javax.transaction;resolution:=optional,
*javax.xml.bind,**
**javax.xml.namespace,**
**javax.xml.parsers,**
**javax.xml.xpath,*
oracle.sql;resolution:=optional,
org.jboss.logging;resolution:=optional,
org.jboss.naming;resolution:=optional,
org.jboss.system;resolution:=optional,
*org.quartz,**
**org.quartz.core,**
**org.quartz.impl.matchers,**
**org.quartz.impl.triggers,**
**org.quartz.jobs;resolution:=optional,**
**org.quartz.spi,**
**org.slf4j;version="[1.6,2)",*
org.terracotta.toolkit;resolution:=optional,
org.terracotta.toolkit.atomic;resolution:=optional,
org.terracotta.toolkit.builder;resolution:=optional,
org.terracotta.toolkit.cluster;resolution:=optional,
org.terracotta.toolkit.collections;resolution:=optional,
org.terracotta.toolkit.concurrent.locks;resolution:=optional,
org.terracotta.toolkit.config;resolution:=optional,
org.terracotta.toolkit.internal;resolution:=optional,
org.terracotta.toolkit.internal.concurrent.locks;resolution:=optional,
org.terracotta.toolkit.rejoin;resolution:=optional,
org.terracotta.toolkit.search;resolution:=optional,
org.terracotta.toolkit.search.attribute;resolution:=optional,
org.terracotta.toolkit.store;resolution:=optional,
*org.w3c.dom,**
**org.xml.sax,*
weblogic.jdbc.jts;resolution:=optional,
weblogic.jdbc.vendor.oracle;resolution:=optional
Why would I need javax.sql, javax.servlet, w3c, etc... to make cron
jobs? To me as *the end user of this bundle* this make no sense!
However, I can see why this happens; this bundles is *coarse-grained*,
which is against the desired design of bundles. According to literature
all bundles should be *fine-grained*, having *very concise
responsibilities* and as a consequence, *only import the required
dependencies for those responsibilities* (these books cover this very
well http://www.kirkk.com/modularity/chapters/ and
http://shop.oreilly.com/product/0636920033158.do, and so does this one
https://www.manning.com/books/osgi-in-action). So arguments like the
ones I've received before "this is the OSGi way, get used to it or leave
it" are in my opinion invalid, since every OSGi and modular programming
book states that *bulky coase-grained bundles**are a very bad practice*.
To make things worse, these are not a bundles, these are entire projects
wrapped into a single jar having a MANIFEST.MF file. In the end, I see
that my only option, as of now, is to import manually each quartz
dependency, one by one, until no unresolved imports are left or class
not found exceptions are thrown (yeah, because most of those transitive
dependencies are not bundles!). However, finding a solution for this
specific bundle will only help me this time and will probably be based
on mere luck because due to the circumstances of what I am importing.
Since I am a frequent user of OSGi it will be just a mater of time until
I face the dependency hell again with another third-party import,
*because this problem has no publicly available solution so far*. So, my
despair exists for deeper reasons, greater than the "minor" issues I am
facing importing quartz, *which is just one instance of the _OSGi
__dependency hell __problem_*.
I have been in several projects these last 2 years which tried to make
use of OSGi. These three issues were prevalent:
* *Lack of up-to-date documentation *about the tools we should use to
build, manage and deploy OSGi projects (maven-bundle-plugin, tycho,
bndtools, gradle, bnd, ant, karaf, etc.), most examples are just
"hello-world" examples, and none of them cares with dependency management;
* *Lack of a dependency management system *to automatically resolve
transitive dependencies;
* *The OSGi community size is very small*, and the few people who try to
contribute do not always follow the good practices (specially with the
bundelization of third-party libraries, were many imports are left
unresolved in the final bundle, or the third-party library isn't divided
into fine-grained bundles---which I am aware it is a very hard
achievement for most libraries, since most of them depend on the whole
Internet).
*In the end these are the reasons why everyone I know quits OSGi.*
Compare the effort of (i) in a basic Eclipse project you import the
quartz jar to the build path, you use it, build the project and
everything goes fine. In contrast with (ii) OSGi you import quartz to
your OSGi container (usually Felix, unless you want to mess with Equinox
in an Eclipse environment, which is another badly documented mess
<http://www.amazon.com/OSGi-Equinox-Creating-Modular-Systems/dp/0321585712/ref=sr_1_1?ie=UTF8&qid=1445262671&sr=8-1&keywords=equinox+osgi>),
and when you try to launch your container you witness the gates of hell
opening before you.
I have searched, made blog posts, made stackoverflow posts
<http://stackoverflow.com/questions/23737169/managing-osgi-dependency-hell>
asking about the transitive dependencies issue in OSGi, it seems that
there is no solution so far... or if there is, it is not documented. It
doesn't help just answering "ah use this or that tool", no... there must
be documentation, not just for "hello-world" scenarios where you have
little or no dependencies, not just to this specific quartz transitive
dependency, but *for all transitive dependencies*. And remember;
undocumented tools do not exist, only for their creators.
I am sure that I am beating some people out of their comfort zone with
this e-mail, and being unfair to some other. But I can't take it
anymore. No matter how hard I try to defend the OSGi project, because I
truly believe in the philosophy behind *_true_ modular programming*
(like those books explain), I cannot keep pushing forward alone. Most of
the times I feel I am alone in this community, and in the end I don't
even understand how can the authors of those books put in practice their
teachings in a mess like this...! In the end this e-mail reflect my most
honest experience with OSGi, which results in both lack of knowledge and
lack of guidance/documentation to develop real world applications in
OSGi (which I can relate with every OSGi developer I know, so it isn't
solely a problem I am living, but a lot of people's problem when using
OSGi).
Sorry...
Pedro D.
On 13/10/2015 23:24, Pedro Domingues wrote:
Thank you guys for your suggestions. I am gonna try them to see what fits best!
Best regards
On October 12, 2015 10:28:09 PM WEST, Paulo Renato de
Athaydes<renatoathay...@hotmail.com> wrote:
Yeah, I had already suggested that was probably the best solution....
My previous message had a huge blank space in the middle which I have
no idea where it came from!!
But it became a personal challenge to get that old c3p0 jar and quartz
working in a OSGi environment.
:)
Renato
Date: Mon, 12 Oct 2015 23:23:27 +0200
Subject: Re: Help in using your Quartz OSGi bundle
From:fr...@frankjlangel.com
To:us...@felix.apache.org
Have you considered using amdatu-scheduling, a fully wrapped Quartz
OSGI bundle?
On 10/12/15, 11:16 PM, "Neil Bartlett"<njbartl...@gmail.com> wrote:
The import of the c3p0 package is problematic because c3p0 is not an
OSGi bundle. However there is a bundle wrapping availabe:
http://jpm4j.org/#!/p/sha/376EA3C3654A3E0593D1C135A7109ECE77D0BE70//0.0.0
Incidentally, c3p0 apparently hasn’t been updated or maintained for
over 8 years, so it’s a bit dubious to be using something like that in
a production application.
Neil
On 12 Oct 2015, at 22:07, Paulo Renato de Athaydes
<renatoathay...@hotmail.com> wrote:
The quartz bundle has the following imports:
Import-Package:
com.mchange.v2.c3p0,commonj.work;resolution:=optional,
javax.ejb;resolution:=optional,javax.jms;resolution:=optional,javax.m
ail;resolution:=optional,javax.mail.internet;resolution:=optional,jav
ax.management,javax.management.openmbean,javax.naming,javax.servlet;r
esolution:=optional,javax.servlet.http;resolution:=optional,javax.sql
;resolution:=optional,javax.transaction;resolution:=optional,javax.xm
l.bind,javax.xml.namespace,javax.xml.parsers,javax.xml.xpath,oracle.s
ql;resolution:=optional,org.jboss.logging;resolution:=optional,org.jb
oss.naming;resolution:=optional,org.jboss.system;resolution:=optional
,org.quartz,org.quartz.core,org.quartz.impl.matchers,org.quartz.impl.
triggers,org.quartz.jobs;resolution:=optional,org.quartz.spi,org.slf4
j;version="[1.6,2)",org.terracotta.toolkit;resolution:=optional,org.t
erracotta.toolkit.atomic;resolution:=optional,org.terracotta.toolkit.
builder;resolution:=optional,org.terracotta.toolkit.cluster;resolutio
n:=optional,org.terracotta.toolkit.collections;resolution:=optional,o
rg.terracotta.toolkit.concurrent.locks;resolution:=optional,org.terra
cotta.toolkit.config;resolution:=optional,org.terracotta.toolkit.inte
rnal;resolution:=optional,org.terracotta.toolkit.internal.concurrent.
locks;resolution:=optional,org.terracotta.toolkit.rejoin;resolution:=
optional,org.terracotta.toolkit.search;resolution:=optional,org.terra
cotta.toolkit.search.attribute;resolution:=optional,org.terracotta.to
olkit.store;resolution:=optional,org.w3c.dom,org.xml.sax,weblogic.jdb
c.jts;resolution:=optional,weblogic.jdbc.vendor.oracle;resolution:=op
tional
The required dependencies (not optional) are the following:
com.mchange.v2.c3p0
javax.managementjavax.management.openmbean
javax.naming
javax.xml.bind
javax.xml.namespace
javax.xml.parsers
javax.xml.xpath
org.quartz
org.quartz.core
org.quartz.impl.matchers
org.quartz.impl. triggers
org.quartz.spi
org.slf4 j;version="[1.6,2)"
org.w3c.dom
org.xml.sax
The first one, c3p0, comes from this artifact:
"c3p0:c3p0:0.9.1.1"
Which is not a OSGi bundle. (the others, except quartz which comes
>from the jar itself, don't seem to be a problem as the framework seems
happy to provide those).
I wrapped it in a bundle anyway using osgi-run and then, after
installing them in Felix, I found out we need some logging libraries,
org.sfl4j.api, org.apache.log4j, osg.slf4j.impl (ouch!)
A little bit painful to get this working.
After a little guesswork, I found these 2 bundles meet the logging
demands:
osgiRuntime 'org.slf4j:slf4j-simple:1.7.5'
osgiRuntime "org.slf4j:log4j-over-slf4j:1.7.5"
But Felix threw horrible errors when I did this:
ERROR: Bundle slf4j.api [8] Error starting
file:/Users/renato/programming/projects/osgi-run/osgi-run-test/quartz-sample/build/osgi/bundle/slf4j-api-1.6.6.jar
(java.lang.ArrayIndexOutOfBoundsException: -1)
java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.elementData(ArrayList.java:418)
at java.util.ArrayList.remove(ArrayList.java:495)
at
org.apache.felix.framework.resolver.Candidates.prepare(Candidates.java:763)
at
org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:122)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:405)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3973)
at
org.apache.felix.framework.Felix.startBundle(Felix.java:2043)
at
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1297)
at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)
at java.lang.Thread.run(Thread.java:745)
ERROR: Bundle slf4j.api [9] Error starting
file:/Users/renato/programming/projects/osgi-run/osgi-run-test/quartz-sample/build/osgi/bundle/slf4j-api-1.7.5.jar
(java.lang.ArrayIndexOutOfBoundsException: -1)
java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.elementData(ArrayList.java:418)
at java.util.ArrayList.remove(ArrayList.java:495)
at
org.apache.felix.framework.resolver.Candidates.prepare(Candidates.java:763)
at
org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:122)
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:405)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3973)
at
org.apache.felix.framework.Felix.startBundle(Felix.java:2043)
at
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1297)
at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)
at java.lang.Thread.run(Thread.java:745)
____________________________
Welcome to Apache Felix Gogo
Looks like a bug to me (probably fixed now, this is an older Felix
version)...
But I seem to have put two versions of slf4j in the classpath
inadvertently.. anyway, why wouldn't it work? I don't know...
So, after some more research, I found that in the docs of c3p0,
they say this:
Just put the files lib/c3p0-0.9.5.1.jar and
lib/mchange-commons-java-0.2.10.jar in your application's effective
CLASSPATH
So I put this mchange-commons-java jar wrapped into an OSGi bundle
in the framework.... still, didn't work.
With Equinox I get this now:
Framework is launched.
id State Bundle
0 ACTIVE org.eclipse.osgi_3.7.1.R37x_v20110808-1106
1 ACTIVE c3p0_0.9.1.1
2 ACTIVE log4j.over.slf4j_1.7.5
3 INSTALLED mchange-commons-java_0.2.10
4 ACTIVE slf4j.api_1.7.5
Fragments=5
5 RESOLVED slf4j.simple_1.7.5
Master=4
But still didn't work. Didn't even tell me what's wrong.
In Felix, at least I got this error:
org.osgi.framework.BundleException: Unresolved constraint in
bundle mchange-commons-java [3]: Unable to resolve 3.0: missing
requirement [3.0] osgi.wiring.package;
(osgi.wiring.package=com.typesafe.config)
So, apparently, we also need some TypeSafe stuff in the classpath
:(
With this, I just give up.
I recommend you have a look at Atmandu Scheduler instead... It's
made for OSGi and apparently uses Quartz:
http://www.amdatu.org/components/scheduling.html
Good luck!
And.... I can totally understand how you might feel frustrated
about this... I thought I would manage to get this working in a few
minutes... took me hours trying, and nothing :(
What can we do?!
Regards,
Renato
Subject: Re: Help in using your Quartz OSGi bundle
To:us...@felix.apache.org
From:j...@nanthrax.net
Date: Mon, 12 Oct 2015 14:32:04 +0200
Hi Pedro,
such dependencies should be optional. Let me check the SMX quartz
bundle
around this.
Regards
JB
On 10/11/2015 01:20 PM, Pedro Domingues wrote:
Greetings,
Sorry for bothering you, but I would like to ask for your help
with your
Quartz bundle.
I am trying to install your Quartz OSGi bundle into my project:
http://i.imgur.com/PKHnWIj.png
However when I insert the bundle in my *Apache Felix* I keep
getting the
unresolved dependencies error message like you can see here:
java -jar bin/felix.jar
ERROR: Bundle hydra.launcher [1] Error starting
file:/C:/code/hydra/felix/bundle/hydra.launcher-1.0.0-SNAPSHOT.jar
(org.osgi.fram
ework.BundleException: Unable to resolve
org.apache.servicemix.bundles.quartz [8](R 8.0): missing
requirement
[org.apache.servicemix.bundles.quartz [8
](R 8.0)] osgi.wiring.package;
(osgi.wiring.package=org.jboss.logging)
Unresolved requirements: [[org.apache.servicemix.bundles.quartz
[8](R
8.0)] osg
i.wiring.package; (osgi.wiring.package=org.jboss.logging)])
org.osgi.framework.BundleException:*Unable to resolve
org.apache.servicemix.bundles.quartz [8](R 8.0): missing
requirement*
[org.apache.servicemix.bund
les.quartz [8](R 8.0)] osgi.wiring.package;
(osgi.wiring.package=org.jboss.logging) Unresolved requirements:
[[*org.apache.servicemix.bundles.quartz* [8
](R 8.0)] osgi.wiring.package;
(*osgi.wiring.package=org.jboss.logging*)]
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4090)
at
org.apache.felix.framework.Felix.startBundle(Felix.java:2111)
at
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:977)
at
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:964)
at
hydra.launcher.Launcher.installStart(Launcher.java:78)
If I try to discard this dependency manually in your bundle's
manifest I
keep getting other dependencies such as oracle.sql and so on...
It is a
true dependency hell.
However I do not need to use SQL nor JBOSS, I just want to use
Quartz.
Is there any way I can solve this? Do I really need to include
the
thousand transitive dependencies manually, which I will probably
never
use but since these manifests are automatically generated they
include
them anyways?
This is the one thing that makes OSGi hard to use...
Thanks!
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend -http://www.talend.com
---------------------------------------------------------------------
To unsubscribe, e-mail:users-unsubscr...@felix.apache.org
For additional commands, e-mail:users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail:users-unsubscr...@felix.apache.org
For additional commands, e-mail:users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail:users-unsubscr...@felix.apache.org
For additional commands, e-mail:users-h...@felix.apache.org
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
