---------- Forwarded message ---------- From: Karl Pauls <[email protected]> Date: Mon, Jan 9, 2012 at 8:55 PM Subject: Re: Error with multiple instances of Felix running as separate EAR deployments in WebLogic To: [email protected]
Rats. This is a bug. Can you please create a jira issue - we forgot to adapt the URLHandlers during the 4.0 refactoring. Sorry for barking up the wrong tree. Good catch. regards, Karl On Mon, Jan 9, 2012 at 8:50 PM, Karl Pauls <[email protected]> wrote: > hm, this is strange. If the call is comming from inside the framework, > we should find the framework. I'll have to investigate.... > > You sure the blueprint/sping classes are not on the classpath of the > framework and (boot-) delegated down into it? > > regards, > > Karl > > On Mon, Jan 9, 2012 at 8:18 PM, Steele, Richard <[email protected]> wrote: >> Let me know if the following doesn't answer your questions. >> >> The war that's embedded inside the ear contains a listener class that >> bootstraps Felix. (Actually, it bootstraps whatever OSGi container it >> finds in WEB-INF/lib using the Java 6 service extension mechanism.) Once >> the framework is initialized we install and start bundles found in the >> WEB-INF/bundles directory, using the start level service to ensure some >> kind of reproducible ordering. (This actually came in handy to work around >> an issue we had starting up Spring.) >> >> We have the following "system" bundles installed with the specified start >> levels: >> >> org.apache.felix.configadmin=2 >> org.apache.felix.http.bridge=2 >> org.apache.felix.log=2 >> org.apache.felix.metatype=2 >> com.springsource.org.aopalliance=4 >> com.springsource.org.apache.commons.beanutils=4 >> com.springsource.org.apache.commons.collections=4 >> org.eclipse.gemini.blueprint.core=4 >> org.eclipse.gemini.blueprint.extender=4 >> org.eclipse.gemini.blueprint.io=4 >> org.springframework.aop=4 >> org.springframework.asm=4 >> org.springframework.beans=4 >> org.springframework.context=4 >> org.springframework.core=4 >> org.springframework.expression=4 >> org.springframework.transaction=4 >> org.springframework.integration=4 >> >> The remaining (application) bundles are installed at start level 10. >> >> When we try to start with felix.service.urlhandlers set to false, we get >> the following error from Spring: >> >> [ERROR] DependencyWaiterApplicationContextExecutor - Unable to create >> application context for [com.example.foo], unsatisfied dependencies: none >> <org.springframework.beans.factory.BeanDefinitionStoreException: >> IOException parsing XML document from OSGi >> resource[bundle://41.0:0/OSGI-INF/blueprint/blueprint-context.xml|bnd.id=41|bnd.sym=com.example.foo]; >> nested exception is java.net.MalformedURLException: unknown protocol: >> bundle>org.springframework.beans.factory.BeanDefinitionStoreException: >> IOException parsing XML document from OSGi >> resource[bundle://41.0:0/OSGI-INF/blueprint/blueprint-context.xml|bnd.id=41|bnd.sym=com.example.foo]; >> nested exception is java.net.MalformedURLException: unknown protocol: bundle >> at >> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:341) >> at >> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:302) >> at >> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:143) >> at >> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:178) >> at >> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:149) >> at >> org.eclipse.gemini.blueprint.context.support.OsgiBundleXmlApplicationContext.loadBeanDefinitions(OsgiBundleXmlApplicationContext.java:170) >> at >> org.eclipse.gemini.blueprint.context.support.OsgiBundleXmlApplicationContext.loadBeanDefinitions(OsgiBundleXmlApplicationContext.java:140) >> at >> org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:130) >> at >> org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:467) >> at >> org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext.access$800(AbstractDelegatedExecutionApplicationContext.java:60) >> at >> org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext$3.run(AbstractDelegatedExecutionApplicationContext.java:242) >> at >> org.eclipse.gemini.blueprint.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85) >> at >> org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext.startRefresh(AbstractDelegatedExecutionApplicationContext.java:220) >> at >> org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.stageOne(DependencyWaiterApplicationContextExecutor.java:224) >> at >> org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.refresh(DependencyWaiterApplicationContextExecutor.java:177) >> at >> org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:157) >> at >> org.eclipse.gemini.blueprint.extender.internal.activator.LifecycleManager$1.run(LifecycleManager.java:221) >> at java.lang.Thread.run(Thread.java:619) >> Caused by: java.net.MalformedURLException: unknown protocol: bundle >> at java.net.URL.<init>(URL.java:574) >> at java.net.URL.<init>(URL.java:464) >> at java.net.URL.<init>(URL.java:413) >> at >> org.eclipse.gemini.blueprint.io.OsgiBundleResource.getURL(OsgiBundleResource.java:220) >> at >> org.eclipse.gemini.blueprint.io.OsgiBundleResource.getInputStream(OsgiBundleResource.java:181) >> at >> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:328) >> ... 17 more >> >> Thanks, >> Rich >> >> On Mon, Jan 9, 2012 at 1:50 PM, Karl Pauls <[email protected]> wrote: >> >>> After thinking some more about this I'm not so sure anymore I >>> understand what is going on correctly. It looks like the url is >>> generated by us -- hence, it should be working unless it is >>> toString()'ed _and_ recreated outside the framework. >>> >>> Can you maybe share a little bit more about your set-up (ie., how do >>> you embed felix and how are bundles - esp. blueprint - installed and >>> used - esp. in combination with spring - etc.)? >>> >>> regards, >>> >>> Karl >>> >>> On Mon, Jan 9, 2012 at 5:44 PM, Karl Pauls <[email protected]> wrote: >>> > On Mon, Jan 9, 2012 at 5:38 PM, Richard S. Hall <[email protected]> >>> wrote: >>> >> >>> >> >>> >> On 1/9/12 10:08 , Steele, Richard wrote: >>> >>> >>> >>> On Mon, Jan 9, 2012 at 8:46 AM, Karl Pauls<[email protected]> >>> wrote: >>> >>> >>> >>> Sorry for the late reply - still in vacation mode :-). >>> >>> No need to apologize! >>> >>> >>> >>> >>> >>>> Your problem is a tricky one namely, >>> >>>> >>> >>>> spring (or blueprint) is creating bundle: urls manually (or >>> >>>> toString()ing bundle urls and then creating them again). >>> >>>> >>> >>> This is a problem in itself as bundle: urls are not spec'ed (ie., they >>> >>>> >>> >>>> are guessing). They get the format right but the problem is that we >>> >>>> need to know the framework the bundle is in and this information is >>> >>>> lost (the bundle: url doesn't say which framework it targets). >>> >>>> >>> >>> Is this an invalid assumption that Eclipse Gemini Blueprint is making >>> >>> then? Should a defect be reported to them? >>> >> >>> >> >>> >> It depends, it they are taking one of our bundle: URLs and simply >>> >> toString()'ing it, then we can possibly make this work by adding a >>> framework >>> >> ID to our bundle: URL. If they are constructing one from scratch, then >>> we'd >>> >> likely still have the issue. >>> >> >>> >> >>> >>> >>> >>> >>> >>>> We do handle multiple framework instances as we have a simple >>> >>>> heuristic in place: if there is only one running/registered framework >>> >>>> inside the vm then use that one (i.e., it works in this case). If >>> >>>> there are more, fail. >>> >>>> >>> >>>> You are running in the second case :-( >>> >>>> >>> >>> Yes. >>> >> >>> >> >>> >> To be clear, our solution works if you have multiple framework >>> instances as >>> >> long as you aren't either (1) constructing bundle: URLs by hand or (2) >>> >> toString()'ing bundle: URLs. >>> >> >>> >> It would seem you are getting into the failure case because one of >>> these two >>> >> is happening. >>> >> >>> >> >>> >>> >>> >>> For other protocols the same problem exists only if the handler is a >>> >>>> >>> >>>> URLHandlers Service (and not provided by the environment) and can be >>> >>>> made a little less problematic by setting >>> >>>> felix.service.urlhandlers=false. Unfortunately, for you, spring needs >>> >>>> the data and insists on using a bundle: url -- hence, you can't set >>> >>>> the property to false. >>> >>>> >>> >>> So in general with well-behaved bundles setting >>> felix.service.urlhandlers >>> >>> to false ought to work? >>> >>> >>> >>> >>> >>>> I was at one point proposing to encode a known framework id into the >>> >>>> bundle: url in order to resolve this issue but it didn't make it spec >>> >>>> and as a consequence, even if I'd add one, spring wouldn't know about >>> >>>> it. >>> >> >>> >> >>> >> As of R4.3, we do have a framework ID spec, so we could do this, but it >>> >> would still only solve case (2) above. As long as that is your case, >>> then it >>> >> would work. >>> > >>> > Yeah, we should use the framework ID. Please open a bug for this. >>> > >>> > regards, >>> > >>> > Karl >>> > >>> >> Could you open up a bug for us to consider adding a framework ID on >>> bundle: >>> >> URLs? Thanks. >>> >> >>> >> -> richard >>> >> >>> >> >>> >>>> >>> >>>> I'm not sure how to tackle your problem. Why do you need two >>> >>>> frameworks in the first place? Can't you run both apps inside the same >>> >>>> framework? Otherwise, maybe not using spring helps (not sure about >>> >>>> blueprint). >>> >>>> >>> >>> The "why" is because our system administrators say so. :-( This could >>> >>> perhaps be renegotiated given our current troubles, especially since >>> there >>> >>> doesn't appear to be an easy answer to this. >>> >>> >>> >>> (I hate to even ask on this forum, but does anyone know if other OSGi >>> >>> implementations have the same issue?) >>> >>> >>> >>> We're using Spring because as far as I know that's what Gemini >>> Blueprint >>> >>> requires. We're using Blueprint because many of our developers are >>> >>> already >>> >>> very familiar with Spring and DI in general. >>> >>> >>> >>> regards, >>> >>>> >>> >>>> Karl >>> >>>> >>> >>> Thanks, >>> >>> Rich >>> >>> >>> >> >>> >> --------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: [email protected] >>> >> For additional commands, e-mail: [email protected] >>> >> >>> > >>> > >>> > >>> > -- >>> > Karl Pauls >>> > [email protected] >>> > http://twitter.com/karlpauls >>> > http://www.linkedin.com/in/karlpauls >>> > https://profiles.google.com/karlpauls >>> >>> >>> >>> -- >>> Karl Pauls >>> [email protected] >>> http://twitter.com/karlpauls >>> http://www.linkedin.com/in/karlpauls >>> https://profiles.google.com/karlpauls >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> > > > > -- > Karl Pauls > [email protected] > http://twitter.com/karlpauls > http://www.linkedin.com/in/karlpauls > https://profiles.google.com/karlpauls -- Karl Pauls [email protected] http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls -- Karl Pauls [email protected] http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls
