Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Equinox » An Interesting Integration Problem(bundleresource abstraction is screwing up integration effort)
An Interesting Integration Problem [message #660665] Sun, 20 March 2011 21:41 Go to next message
Robert Brown III is currently offline Robert Brown III
Messages: 35
Registered: July 2009
Member
Greetings:

I am attempting to integrate an embeddable application int Equinox, using an API that the application provides for embedding. I have put together a bundle that calls the API, and I can start the application from within the container.

The problem is that, during initialization, the application code throws an exception that causes its bundle to fail to load.

After some debugging and tracing, I found what was causing the exception: the embedded code has a classloader that loads several JAR files from the classpath. It references these files as URLs whose protocols are jar:file. In a test application that I run, this is not a problem, but within Equinox the container imposes its bundleresource protocol on all files within the classpath, which the application code cannot process. This is what is causing the exception.

This use of bundleresource within Equinox is a real problem for integration, limiting what can be done to integrate various libraries and applications. Based on my research, it has been a problem for several years now. I am hoping that by now some folks have comne up with solutions to this problem. That is why I am here making inquiries.

The problem boils down to an inability to use the "regular" Equinox mechanisms for handling classpaths with this particular application. Based on this, I must ask the following:

1. Is it possible to set classpaths outside of the container, such that Equinox's bundleresource mechanism won't convert the URLs? If so, then that would resolve my problem neatly.

2. If I remember correctly, there may be a way to add classpaths programmaticly. If there is, it may be possible to dynamically set the classpaths just before I actually initialize the application. If I do this, will I still be subject to Equinox's bundleresource mechanisms?

3. Is there some way to disable the bundleresource mechanism for a specific bundle, or to at least translate bundleresaource URLs into jar:file URLs?

These are the approaches I can think of offhand. Are there any alternate solutions?

Someone please advise.
Re: An Interesting Integration Problem [message #660740 is a reply to message #660665] Mon, 21 March 2011 12:44 Go to previous messageGo to next message
Thomas Watson is currently offline Thomas Watson
Messages: 436
Registered: July 2009
Senior Member
Robert Brown III wrote on Sun, 20 March 2011 16:41
Greetings:

I am attempting to integrate an embeddable application int Equinox, using an API that the application provides for embedding. I have put together a bundle that calls the API, and I can start the application from within the container.

The problem is that, during initialization, the application code throws an exception that causes its bundle to fail to load.

After some debugging and tracing, I found what was causing the exception: the embedded code has a classloader that loads several JAR files from the classpath. It references these files as URLs whose protocols are jar:file. In a test application that I run, this is not a problem, but within Equinox the container imposes its bundleresource protocol on all files within the classpath, which the application code cannot process. This is what is causing the exception.



How does the embedded code discover the URLs where the jars are? Is it looking for all manifests by using ClassLoader.getResources?

Quote:


This use of bundleresource within Equinox is a real problem for integration, limiting what can be done to integrate various libraries and applications. Based on my research, it has been a problem for several years now. I am hoping that by now some folks have comne up with solutions to this problem. That is why I am here making inquiries.

The problem boils down to an inability to use the "regular" Equinox mechanisms for handling classpaths with this particular application. Based on this, I must ask the following:

1. Is it possible to set classpaths outside of the container, such that Equinox's bundleresource mechanism won't convert the URLs? If so, then that would resolve my problem neatly.




What class path are you referring to? The bundle class path set by the Bundle-ClassPath header? I am a bit confused why the Bundle-ClassPath would be used to load jars up into another (non-osgi bundle) class loader. The Bundle-ClassPath header is intended to define the class path for a bundle's class loader.

Quote:


2. If I remember correctly, there may be a way to add classpaths programmaticly. If there is, it may be possible to dynamically set the classpaths just before I actually initialize the application. If I do this, will I still be subject to Equinox's bundleresource mechanisms?




There is no such mechanism.

Quote:


3. Is there some way to disable the bundleresource mechanism for a specific bundle, or to at least translate bundleresaource URLs into jar:file URLs?



No, not at this time.

Quote:


These are the approaches I can think of offhand. Are there any alternate solutions?

Someone please advise.



Are you able to supply the URLs to the embedded (container?) code that creates the brittle class loader where the content must be jar:file:? If so then you could use the method org.eclipse.core.runtime.FileLocator.resolve(URL) to resolve the URL into a jar: URL.

Tom

Re: An Interesting Integration Problem [message #660992 is a reply to message #660740] Tue, 22 March 2011 15:37 Go to previous messageGo to next message
Robert Brown III is currently offline Robert Brown III
Messages: 35
Registered: July 2009
Member
Greetings, Tom.

Thanks for your response. Responding to your questions:

1. ClassLoader.getResources() is exactly what the embedded code is using. The main difference is that the classloader being used is apparently their own classloader.

2. Clarification is required to overcome your confusion:

The embedded code that I am using is in a bundle. In order for it to even start up, I have to place a number of JARs into the Bundle-ClassPath section of the Manifest. The problem is that several of the necessary JAR files are the ones that the embedded code attempts to load using getResources(), which in turn gets the bubdleresource URLs and causes the exception(s) to be thrown.

What I was asking about is an alternate way to set classpaths so that my embedded code doesn't have to get its JAR files through the Manifest. I was hoping for a command line parameter (like the -D used by the Java runtime) that would enable me to run the embedded code without having to put all the necessary JAR references into the Bundle-ClassPath part of the bundle's manifest. That way (I was hoping) the application can get its JAR files without having to do so through the container, thus eliminating the bundleresource protocol problem.

The idea was a longshot, but I figured I would ask about it...

3. Unfortunately, I have no control over the source for this embedded application (FYI, the application I am attempting to embed is the Mule ESB), so I cannot supply the URLs to that part of the code that is using the (I agree, it is brittle!) class loader. The only thing I can think of that will allow me to do as you suggest (use the org.eclipse.core.runtime.FileLocator.resolve(URL) method) would be to somehow find a way to inject some code into their class that makes that call when inside an OSGi container. I am looking into the possibility of rewriting the class that uses the brittle classloader, and using it to replace the class that is in their JAR file. Otherwise, I would have to rewrite large portions of their code -- something I do not want to do.

It is looking like this integration may not be possible. Can you (or anyone else, for that matter!) think of any other approaches to solving this problem?
Re: An Interesting Integration Problem [message #661018 is a reply to message #660992] Tue, 22 March 2011 17:47 Go to previous messageGo to next message
Thomas Watson is currently offline Thomas Watson
Messages: 436
Registered: July 2009
Senior Member
You are in some luck. There is a way to make the bundle class loaders behave the way you want. You can use a framework extension that wraps the BundleFile objects and overrides the getResourceURL methods to return the jar:file: URLs you need.


I created an example framework extension project here

http://dl.dropbox.com/u/19482870/jarurls.zip

Basically a framework extension is a fragment of the framework (org.eclipse.osgi) and can hook into the framework to augment the behavior of the framework. You will need to import org.eclipse.osgi into your workspace and also import the above fragment project. Also set the config property:

osgi.framework.extensions=org.eclipse.osgi.jarurls

For more information on framework adaptor hooks see:

http://wiki.eclipse.org/index.php/Adaptor_Hooks

The important code in the example I posted is in the method org.eclipse.osgi.locolurs.LocalURLWrapperFactory.LocalURLWra pper.convertToLocal(URL) which uses some framework internals to convert the bundleresource URLs into local jar:file: URLs.

HTH

Tom
Re: An Interesting Integration Problem [message #661020 is a reply to message #661018] Tue, 22 March 2011 17:54 Go to previous messageGo to next message
Thomas Watson is currently offline Thomas Watson
Messages: 436
Registered: July 2009
Senior Member
Sigh, I created this rather quickly. You will notice the package name "org.eclipse.osgi.locolurs". That is the correct package name that I used in the example. Sorry about that.

Tom.
Re: An Interesting Integration Problem [message #661086 is a reply to message #661020] Wed, 23 March 2011 05:14 Go to previous messageGo to next message
Robert Brown III is currently offline Robert Brown III
Messages: 35
Registered: July 2009
Member
Tom:

Thanks for the info and example. I am in the process of putting the example bundle you gave into my development environment.

A quick question, though: the hook code you provided seems to depend on Version 3.7 of org.eclipse.osgi. The latest version of that bundle I have appears to be 3.6.1.

Assuming that I will need 3.7 in order for this to work properly, where and how can I get that version? s this something I can update?

Please advise.

Re: An Interesting Integration Problem [message #661167 is a reply to message #661086] Wed, 23 March 2011 12:38 Go to previous messageGo to next message
Thomas Watson is currently offline Thomas Watson
Messages: 436
Registered: July 2009
Senior Member
The example should be able to run on 3.6.x. Simply change the following manifest header to include 3.6:

Fragment-Host: org.eclipse.osgi;bundle-version="3.6.0"

Tom
Re: An Interesting Integration Problem [message #661276 is a reply to message #661167] Wed, 23 March 2011 20:09 Go to previous messageGo to next message
Robert Brown III is currently offline Robert Brown III
Messages: 35
Registered: July 2009
Member
Tom:

I'm sorry, this is really embarrassing. I am sorry to bug you further, but I am having some problems:

I have imported your example hook bundle into my Eclipse project, set up some dependencies, and I believe I am using the correct plugin. Apparently, the hooks are not being invoked for some reason. I have a nasty suspicion that I have missed something somewhere.

Below is the contents of the Manifest for the Jarurls bundle, with my modification:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Jarurls
Bundle-SymbolicName: org.eclipse.osgi.jarurls
Bundle-Version: 1.0.0.qualifier
Fragment-Host: org.eclipse.osgi;bundle-version="3.6.1"
Bundle-RequiredExecutionEnvironment: J2SE-1.5
Export-Package: org.eclipse.osgi.locolurs;uses:=" org.eclipse.osgi.baseadaptor.hooks,org.eclipse.osgi.baseadap tor.bundlefile,org.eclipse.osgi.baseadaptor "

Below is the contents of my own bundle that contains the embedded Mule:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Mule
Bundle-SymbolicName: mil.af.ares.esb.mule
Bundle-Version: 3.0.0
Bundle-Activator: mil.af.ares.esb.mule.MuleActivator
Bundle-ActivationPolicy: lazy
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Import-Package: mil.af.ares.esb.intfc,
org.eclipse.osgi.locolurs,
org.osgi.framework;version="1.3.0"
Bundle-ClassPath: .,
lib/mule/mule-core-3.1.0-tests.jar,
lib/mule/mule-core-3.1.0.jar,
lib/mule/mule-module-acegi-3.1.0.jar,
lib/mule/mule-module-annotations-3.1.0.jar,
lib/mule/mule-module-atom-3.1.0.jar,
lib/mule/mule-module-bpm-3.1.0.jar,
lib/mule/mule-module-builders-3.1.0.jar,
lib/mule/mule-module-client-3.1.0.jar,
lib/mule/mule-module-cxf-3.1.0.jar,
lib/mule/mule-module-ibeans-3.1.0.jar,
lib/mule/mule-module-jaas-3.1.0.jar,
lib/mule/mule-module-jbossts-3.1.0.jar,
lib/mule/mule-module-jbpm-3.1.0.jar,
lib/mule/mule-module-jersey-3.1.0.jar,
lib/mule/mule-module-json-3.1.0.jar,
lib/mule/mule-module-launcher-3.1.0.jar,
lib/mule/mule-module-management-3.1.0.jar,
lib/mule/mule-module-ognl-3.1.0.jar,
lib/mule/mule-module-pgp-3.1.0.jar,
lib/mule/mule-module-rss-3.1.0.jar,
lib/mule/mule-module-scripting-3.1.0.jar,
lib/mule/mule-module-spring-config-3.1.0.jar,
lib/mule/mule-module-spring-extras-3.1.0.jar,
lib/mule/mule-module-spring-security-3.1.0.jar,
lib/mule/mule-module-sxc-3.1.0.jar,
lib/mule/mule-module-tomcat-3.1.0.jar,
lib/mule/mule-module-ws-3.1.0.jar,
lib/mule/mule-module-xml-3.1.0.jar,
lib/mule/mule-transport-ajax-3.1.0.jar,
lib/mule/mule-transport-ejb-3.1.0.jar,
lib/mule/mule-transport-email-3.1.0.jar,
lib/mule/mule-transport-file-3.1.0.jar,
lib/mule/mule-transport-ftp-3.1.0.jar,
lib/mule/mule-transport-http-3.1.0.jar,
lib/mule/mule-transport-jdbc-3.1.0.jar,
lib/mule/mule-transport-jetty-3.1.0.jar,
lib/mule/mule-transport-jms-3.1.0.jar,
lib/mule/mule-transport-multicast-3.1.0.jar,
lib/mule/mule-transport-quartz-3.1.0.jar,
lib/mule/mule-transport-rmi-3.1.0.jar,
lib/mule/mule-transport-servlet-3.1.0.jar,
lib/mule/mule-transport-ssl-3.1.0.jar,
lib/mule/mule-transport-stdio-3.1.0.jar,
lib/mule/mule-transport-tcp-3.1.0.jar,
lib/mule/mule-transport-udp-3.1.0.jar,
lib/mule/mule-transport-vm-3.1.0.jar,
lib/mule/mule-transport-xmpp-3.1.0.jar,
lib/boot/commons-cli-1.2.jar,
lib/boot/jcl-over-slf4j-1.6.1.jar,
lib/boot/log4j-1.2.14.jar,
lib/boot/mule-module-boot-3.1.0.jar,
lib/boot/mule-module-reboot-3.1.0.jar,
lib/boot/slf4j-api-1.6.1.jar,
lib/boot/slf4j-log4j12-1.6.1.jar,
lib/boot/wrapper-3.2.3.jar,
lib/endorsed/xalan-2.7.1.jar,
lib/endorsed/xercesImpl-2.9.1.jar,
lib/endorsed/xml-apis-1.3.04.jar,
lib/endorsed/xml-serializer-2.7.1.jar,
lib/opt/abdera-client-0.4.0-incubating.jar,
lib/opt/abdera-core-0.4.0-incubating.jar,
lib/opt/abdera-i18n-0.4.0-incubating.jar,
lib/opt/abdera-parser-0.4.0-incubating.jar,
lib/opt/abdera-server-0.4.0-incubating.jar,
lib/opt/abdera-spring-0.4.0-incubating.jar,
lib/opt/acegi-security-1.0.7-osgi.jar,
lib/opt/activation-1.1-osgi.jar,
lib/opt/ant-1.6.5.jar,
lib/opt/antlr-2.7.6.jar,
lib/opt/aopalliance-1.0.jar,
lib/opt/asm-3.1-osgi.jar,
lib/opt/asm-commons-3.1.jar,
lib/opt/asm-tree-3.1.jar,
lib/opt/aspectjrt-1.5.4.jar,
lib/opt/aspectjweaver-1.6.8.jar,
lib/opt/axiom-api-1.2.5.jar,
lib/opt/axiom-impl-1.2.5.jar,
lib/opt/backport-util-concurrent-3.1-osgi.jar,
lib/opt/bcmail-jdk15-1.45.jar,
lib/opt/bcpg-jdk15-1.45.jar,
lib/opt/bcprov-ext-jdk15-1.45.jar,
lib/opt/bcprov-jdk15-1.45.jar,
lib/opt/bctsp-jdk15-1.45.jar,
lib/opt/cglib-nodep-2.2.jar,
lib/opt/cometd-api-1.0.0rc0.jar,
lib/opt/cometd-server-6.1.22.jar,
lib/opt/commons-beanutils-1.8.0.jar,
lib/opt/commons-codec-1.3-osgi.jar,
lib/opt/commons-collections-3.2.1.jar,
lib/opt/commons-dbutils-1.2.jar,
lib/opt/commons-httpclient-3.1-osgi.jar,
lib/opt/commons-io-1.4.jar,
lib/opt/commons-jxpath-1.3-osgi.jar,
lib/opt/commons-lang-2.4.jar,
lib/opt/commons-net-2.0.jar,
lib/opt/commons-pool-1.5.3.jar,
lib/opt/cxf-api-2.3.0.jar,
lib/opt/cxf-common-schemas-2.3.0.jar,
lib/opt/cxf-common-utilities-2.3.0.jar,
lib/opt/cxf-rt-bindings-soap-2.3.0.jar,
lib/opt/cxf-rt-bindings-xml-2.3.0.jar,
lib/opt/cxf-rt-core-2.3.0.jar,
lib/opt/cxf-rt-databinding-aegis-2.3.0.jar,
lib/opt/cxf-rt-databinding-jaxb-2.3.0.jar,
lib/opt/cxf-rt-frontend-jaxws-2.3.0.jar,
lib/opt/cxf-rt-frontend-simple-2.3.0.jar,
lib/opt/cxf-rt-transports-http-2.3.0.jar,
lib/opt/cxf-rt-transports-local-2.3.0.jar,
lib/opt/cxf-rt-ws-addr-2.3.0.jar,
lib/opt/cxf-rt-ws-rm-2.3.0.jar,
lib/opt/cxf-rt-ws-security-2.3.0.jar,
lib/opt/cxf-tools-common-2.3.0.jar,
lib/opt/cxf-wstx-msv-validation-2.3.0.jar,
lib/opt/dom4j-1.6.1-osgi.jar,
lib/opt/geronimo-annotation_1.0_spec-1.1.1.jar,
lib/opt/geronimo-ejb_2.1_spec-1.1-osgi.jar,
lib/opt/geronimo-j2ee-connector_1.5_spec-1.1-osgi.jar,
lib/opt/geronimo-j2ee-management_1.0_spec-1.1-osgi.jar,
lib/opt/geronimo-jms_1.1_spec-1.1-osgi.jar,
lib/opt/geronimo-jta_1.0.1B_spec-1.1-osgi.jar,
lib/opt/geronimo-stax-api_1.0_spec-1.0.1.jar,
lib/opt/groovy-all-1.6.7.jar,
lib/opt/hibernate-commons-annotations-3.2.0.Final.jar,
lib/opt/hibernate-core-3.6.0.Final.jar,
lib/opt/hibernate-jpa-2.0-api-1.0.0.Final.jar,
lib/opt/ibeans-annotation-api-0.9.2-SNAPSHOT.jar,
lib/opt/ibeans-support-1.0-SNAPSHOT.jar,
lib/opt/isorelax-20030108.jar,
lib/opt/jackson-core-asl-1.3.1.jar,
lib/opt/jackson-jaxrs-1.3.1.jar,
lib/opt/jackson-mapper-asl-1.3.1.jar,
lib/opt/javassist-3.7.ga.jar,
lib/opt/jaxb-api-2.1-osgi.jar,
lib/opt/jaxb-impl-2.1.9-osgi.jar,
lib/opt/jaxb-xjc-2.1.9-osgi.jar,
lib/opt/jaxen-1.1.1-osgi.jar,
lib/opt/jaxws-api-2.2.1.jar,
lib/opt/jbossts-common-4.2.3-SP5-osgi.jar,
lib/opt/jbossts-jta-4.2.3-SP5-patched-osgi.jar,
lib/opt/jbossts-jta-integration-4.2.3-SP5-osgi.jar,
lib/opt/jbpm-api-4.4.jar,
lib/opt/jbpm-jpdl-4.4.jar,
lib/opt/jbpm-log-4.4.jar,
lib/opt/jbpm-pvm-4.4.jar,
lib/opt/jdom-1.0-osgi.jar,
lib/opt/jersey-core-1.3.jar,
lib/opt/jersey-json-1.3.jar,
lib/opt/jersey-server-1.3.jar,
lib/opt/jetty-6.1.22.jar,
lib/opt/jetty-util-6.1.22.jar,
lib/opt/jetty-util5-6.1.22.jar,
lib/opt/joda-time-1.6.jar,
lib/opt/jsr181-api-1.0-MR1.jar,
lib/opt/jsr250-api-1.0.jar,
lib/opt/jsr311-api-1.1.1.jar,
lib/opt/juel-api-2.2.1.jar,
lib/opt/juel-engine-2.1.0.jar,
lib/opt/juel-impl-2.2.1.jar,
lib/opt/jug-2.0.0-osgi-asl.jar,
lib/opt/livetribe-jsr223-2.0.5.jar,
lib/opt/mail-1.4.3.jar,
lib/opt/mockito-all-1.8.4.jar,
lib/opt/msv-core-2010.1.jar,
lib/opt/mx4j-impl-2.1.1-osgi.jar,
lib/opt/mx4j-jmx-2.1.1-osgi.jar,
lib/opt/mx4j-remote-2.1.1-osgi.jar,
lib/opt/mx4j-tools-2.1.1-osgi.jar,
lib/opt/neethi-2.0.4.jar,
lib/opt/ognl-2.7.3-osgi.jar,
lib/opt/oro-2.0.8-osgi.jar,
lib/opt/quartz-all-1.6.0-osgi.jar,
lib/opt/relaxngDatatype-20020414.jar,
lib/opt/rome-0.9.jar,
lib/opt/saaj-api-1.3-osgi.jar,
lib/opt/saaj-impl-1.3-osgi.jar,
lib/opt/saxon-8.9.0.4-osgi.jar,
lib/opt/saxon-dom-8.9.0.4-osgi.jar,
lib/opt/saxon-xqj-8.9.0.4.jar,
lib/opt/scribe-1.0.3.jar,
lib/opt/servlet-api-2.5-20081211.jar,
lib/opt/smack-3.1.0.jar,
lib/opt/smackx-3.1.0.jar,
lib/opt/spring-aop-3.0.3.RELEASE.jar,
lib/opt/spring-asm-3.0.3.RELEASE.jar,
lib/opt/spring-beans-3.0.3.RELEASE.jar,
lib/opt/spring-context-3.0.3.RELEASE.jar,
lib/opt/spring-core-3.0.3.RELEASE.jar,
lib/opt/spring-expression-3.0.3.RELEASE.jar,
lib/opt/spring-jdbc-3.0.3.RELEASE.jar,
lib/opt/spring-jms-3.0.3.RELEASE.jar,
lib/opt/spring-security-config-3.0.3.RELEASE.jar,
lib/opt/spring-security-core-3.0.3.RELEASE.jar,
lib/opt/spring-security-web-3.0.3.RELEASE.jar,
lib/opt/spring-tx-3.0.3.RELEASE.jar,
lib/opt/spring-web-3.0.3.RELEASE.jar,
lib/opt/stax-utils-20080702-osgi.jar,
lib/opt/stax2-api-3.0.2.jar,
lib/opt/sxc-core-0.7.3-osgi.jar,
lib/opt/sxc-runtime-0.7.3-osgi.jar,
lib/opt/sxc-xpath-0.7.3-osgi.jar,
lib/opt/tomcat-apr-5.5.23.jar,
lib/opt/tomcat-util-5.5.23.jar,
lib/opt/woodstox-core-asl-4.0.8.jar,
lib/opt/wsdl4j-1.6.2.jar,
lib/opt/wss4j-1.5.8-osgi.jar,
lib/opt/xapool-1.5.0-osgi.jar,
lib/opt/xml-resolver-1.2-osgi.jar,
lib/opt/XmlSchema-1.4.7.jar,
lib/opt/xmlsec-1.4.0-osgi.jar,
lib/opt/xpp3_min-1.1.3.4.O-osgi.jar,
lib/opt/xsdlib-2010.1.jar,
lib/opt/xstream-1.2.2-osgi.jar,
lib/user/junit-4.8.1.jar,
lib/user/mule-tests-functional-3.1.0.jar,
lib/user/pojo.jar,
lib/user/xmlunit-1.1.jar
Require-Bundle: org.eclipse.osgi;bundle-version="3.6.1"
Export-Package: mil.af.ares.esb.mule

Now the only thing I wasn't sure of was the configuration setting you mentioned (osgi.framework.extensions), but according to the documentation at the URL you provided, apparently we are supposed to set the property in Eclipse's config.ini file. So I added to that property, so that my config.ini file looks like so:

#This configuration file was written by: org.eclipse.equinox.internal.frameworkadmin.equinox.EquinoxF wConfigFileParser
#Wed Mar 23 02:20:10 EDT 2011
org.eclipse.update.reconcile=false
eclipse.p2.profile=epp.package.jee
osgi.instance.area.default=@user.home/workspace
osgi.framework=file\:plugins/org.eclipse.osgi_3.6.2.R36x_v20 110210.jar
equinox.use.ds=true
eclipse.buildId=M20110210-1200
osgi.bundles=reference\:file\: org.eclipse.equinox.simpleconfigurator_1.0.200.v20100503.jar @1\:start
org.eclipse.equinox.simpleconfigurator.configUrl=file\:org.e clipse.equinox.simpleconfigurator/bundles.info
eclipse.product=org.eclipse.platform.ide
osgi.splashPath=platform\:/base/plugins/org.eclipse.platform
osgi.framework.extensions=org.eclipse.osgi.jarurls,reference \:file\:javax.transaction_1.1.1.v201006150915.jar,reference\ :file\:org.eclipse.equinox.weaving.hook_1.0.0.v20100503.jar
eclipse.p2.data.area=@config.dir/../p2/
eclipse.application=org.eclipse.ui.ide.workbench
osgi.bundles.defaultStartLevel=4

Note that there were other references pointed to by the osgi.framework.extensions property. I added what you suggested to that list...

Despite these things, I continue to get the exception, and when I run things in the debugger they are showing that the hook code never gets called.

Am I missing something?
Re: An Interesting Integration Problem [message #661279 is a reply to message #661276] Wed, 23 March 2011 20:27 Go to previous messageGo to next message
Thomas Watson is currently offline Thomas Watson
Messages: 436
Registered: July 2009
Senior Member
Sorry you are having trouble. My guess is that the launcher is not finding the framework extension. In order for the framework adaptor HookConfigurator to get discovered and called by the framework is if the framework extension is added to the framework's class loader by the launcher.

I should have asked this before, but are you using the equinox launcher (org.eclipse.equinox.launcher with the native launcher)? The org.eclipse.equinox.launcher jar is what is responsible for setting up the class loader for the framework and discovering the framework extensions that need to be configured in. In order for it to easily discover the framework extensions they must be co-located on disk along with the org.eclipse.osgi jar.

If you are not using the equinox launcher then you have to add your jar on the class path along with org.eclipse.osgi yourself when you launch.

HTH

Tom.

P.S. I am not sure why you are exporting the package from the framework extension bundle and importing it into the mule bundle. Are you actually using that package in the mule bundle?
Re: An Interesting Integration Problem [message #661465 is a reply to message #661279] Thu, 24 March 2011 18:36 Go to previous messageGo to next message
Robert Brown III is currently offline Robert Brown III
Messages: 35
Registered: July 2009
Member
>P.S. I am not sure why you are exporting the package from the framework extension bundle and importing it into the mule bundle. Are you actually using that package in the mule bundle?

No, I am not. That particular entry in my manifest was the result of my confusion. I didn't realize that the entry was redundant until I read your post. It has been removed from my manifest.

To answer your main question: I think I am using the correct Equinox launcher. I am running Equinox from within the Eclipse IDE, and the debugger shows the main process as starting at "org.eclipse.equinox.launcher.Main". I do not yet know how to use another launcher.

Other things I am doing are exporting your example bundle into a file called org.eclipse.osgi.jarurls.jar, and placing that file into Eclipse's plugins directory, because that is where the org.eclipse.osgi jar file is (actually, the Jars I found were org.eclipse.osgi_3.6.1.R36x_v20100806.jar and org.eclipse.osgi_3.6.2.R36x_v20110210.jar). Note that because I found a 3.6.2 version of the bundle, I changed the manifest in org.eclipse.osgi.jarurls to reflect the newer version. This hasn't changed anything, though. Regardless of the version org.eclipse.osgi is not finding or loading org.eclipse.osgi.jarurls.

You mention that the "easy" way to get the org.eclipse.osgi bundle to discover framework extensions is to co- locate the
framework extensions with the org.eclipse.osgi bundle. Is there a "hard" way to do this? The easy way does not appear to be working, at least not in my IDE environment and eventually I am going to want to deploy what I have anyway. When I do the deploy I will probably want to use a different launcher (like P2?). Is there a mechanism for making the org.equinox.osgi bundle load a specific framework extension? Is there a way that I can set the classpath that org.equinox.osgi can use to find all available framework extensions?
Re: An Interesting Integration Problem [message #661477 is a reply to message #661465] Thu, 24 March 2011 19:27 Go to previous messageGo to next message
Thomas Watson is currently offline Thomas Watson
Messages: 436
Registered: July 2009
Senior Member
OK, this clears things up for me. So you are doing the typical self-hosting launch from the Eclipse IDE to launch another instance for running/debugging your code. Try setting the following as a VM argument in the launch configuration use use to launch eclipse:

-Dosgi.framework.extensions=org.eclipse.osgi.jarurls

Setting this in the config.ini of your installation of Eclipse will not help since I don't think PDE will use that value when launching the instance from the IDE.

Note that p2 is not a launcher, instead it is a provisioning system for managing an eclipse installation. When you create a deployable product you will still use the equinox launcher. The config.ini for that product must have osgi.framework.extensions=org.eclipse.osgi.jarurls set.

If you are using p2 to do this then you can add a p2.inf file to the fragment under META-INF/p2.inf with the following content:

instructions.configure = \
setProgramProperty(propName:osgi.framework.extensions, propValue:org.eclipse.osgi.jarurls);
instructions.unconfigure = \
setProgramProperty(propName:osgi.framework.extensions, propValue:);

This should tell p2 to set that property when the fragment is installed with p2 and unset it when the fragment is uninstalled by p2.
Re: An Interesting Integration Problem [message #661943 is a reply to message #661477] Mon, 28 March 2011 14:53 Go to previous messageGo to next message
Robert Brown III is currently offline Robert Brown III
Messages: 35
Registered: July 2009
Member
Tom:

Thanks for your advise and assistance. I have it working at last.

It turns out that not only did I have to make the addition to the VM parameters that you suggested, but in order to co- locate org.eclipse.osgi with the extension I actually had to import it into my development environment. Once it was in, the extension kicked in and I was able to start my embedded app without problems. So far, it appears to be fully functional.

It occurs to me that it might be a good idea to document what was done here so that others can more easily install and deploy framework extensions. From what I have read, it appears that they can be pretty powerful. I am going to try and learn more about how to make them, but I believe that I could make myself useful here by documenting step- by- step what was necessary to get it to work.

What would be an appropriate venue for such documentation? Is there a Wiki that I should go to, or someone I should email the documentation to so that it can be posted? Or should I document it on a blog of my own?

Please advise.

And again: thanks for your assistance. Most of all, thanks for your patience...

Re: An Interesting Integration Problem [message #661950 is a reply to message #661943] Mon, 28 March 2011 15:09 Go to previous message
Thomas Watson is currently offline Thomas Watson
Messages: 436
Registered: July 2009
Senior Member
I am glad you got it working. I pointed you at a wiki earlier:

http://wiki.eclipse.org/index.php/Adaptor_Hooks

I thought it had mentioned the co-location issues for development time in your workspace, but it does not seem to be clear. Any improvements you can make to that wiki would be much appreciated.

Thanks for offering your help and patience as well!

Tom
Previous Topic:Some Equinox Aspects questions
Next Topic:Container not finding included class
Goto Forum:
  


Current Time: Fri Oct 24 18:05:04 GMT 2014

Powered by FUDForum. Page generated in 0.21325 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software