felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pedro Domingues <pedro.doming...@ist.utl.pt>
Subject Re: Help in using your Quartz OSGi bundle
Date Mon, 19 Oct 2015 13:22:45 GMT
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 <renatoathaydes@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: frank@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" <njbartlett@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
>> <renatoathaydes@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: jb@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é
>>>>>> jbonofre@apache.org
>>>>>> http://blog.nanthrax.net
>>>>>> Talend - http://www.talend.com
>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>> 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
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>> 		 	   		


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message