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 |
Robert Brown III Messages: 36 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 |
Thomas Watson Messages: 503 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 |
Robert Brown III Messages: 36 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 #661276 is a reply to message #661167] |
Wed, 23 March 2011 20:09 |
Robert Brown III Messages: 36 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?
|
|
| | | | | |
Goto Forum:
Current Time: Wed Sep 25 11:03:15 GMT 2024
Powered by FUDForum. Page generated in 0.08520 seconds
|