felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Pauls <karlpa...@gmail.com>
Subject Fwd: Error with multiple instances of Felix running as separate EAR deployments in WebLogic
Date Mon, 09 Jan 2012 19:55:50 GMT
---------- Forwarded message ----------
From: Karl Pauls <karlpauls@gmail.com>
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: users@felix.apache.org


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 <karlpauls@gmail.com> 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 <rich@steelezone.net> 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 <karlpauls@gmail.com> 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 <karlpauls@gmail.com> wrote:
>>> > On Mon, Jan 9, 2012 at 5:38 PM, Richard S. Hall <heavy@ungoverned.org>
>>> wrote:
>>> >>
>>> >>
>>> >> On 1/9/12 10:08 , Steele, Richard wrote:
>>> >>>
>>> >>> On Mon, Jan 9, 2012 at 8:46 AM, Karl Pauls<karlpauls@gmail.com>
>>>  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: users-unsubscribe@felix.apache.org
>>> >> For additional commands, e-mail: users-help@felix.apache.org
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Karl Pauls
>>> > karlpauls@gmail.com
>>> > http://twitter.com/karlpauls
>>> > http://www.linkedin.com/in/karlpauls
>>> > https://profiles.google.com/karlpauls
>>>
>>>
>>>
>>> --
>>> Karl Pauls
>>> karlpauls@gmail.com
>>> http://twitter.com/karlpauls
>>> http://www.linkedin.com/in/karlpauls
>>> https://profiles.google.com/karlpauls
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
> http://twitter.com/karlpauls
> http://www.linkedin.com/in/karlpauls
> https://profiles.google.com/karlpauls



--
Karl Pauls
karlpauls@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls


-- 
Karl Pauls
karlpauls@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls

Mime
View raw message