Guys, so far no luck... Both original quartz library bundle and amdatu
bundle import the following 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?
This bundles is coarse-grained, this is against the desired design of
bundles, which should be fine-grained, having very concise
responsibilities and as a consequence, only the required imports for
those responsibilities (these books cover this very well
http://www.kirkk.com/modularity/chapters/ and
http://shop.oreilly.com/product/0636920033158.do). So arguments like
"this is the OSGi way, get used to it" are invalid since every OSGi and
modular programming book states that *this is a very bad practice*.
These are not a bundles, these are entire projects wrapped into a jar
with a MANIFEST.MF file. I see my only option, as of now, 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!).
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, 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
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 from OSGi,
and I, as an OSGi user have to face on a daily basis.
Compare the effort of, 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 OSGi you import quartz to your OSGi container
(usually Felix, unless you want to mess with equinox in an Eclipse
environment, which is an undocumented mess), 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 asking about
the transitive dependencies issue in OSGi, it seems that there is no
solution so far, of there is, there is no documentation of it. It
doesn't help just saying "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 transitive dependency, but
for all transitive dependencies. Undocumented tools do not exist, only
for their creators.
I am sure I am beating some people out of their comfort zone with this
e-mail but I can't take it anymore. No matter How I try to defend the
OSGi project because I truly believe in the philosophy behind true
modular programming (like the 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 dont even understand how can the authors of those books
put in practice their teachings in a mess like this...!
Sorry...
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: users@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: users@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
