felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Pauls <karlpa...@gmail.com>
Subject Re: Error with multiple instances of Felix running as separate EAR deployments in WebLogic
Date Mon, 09 Jan 2012 20:19:29 GMT
On Mon, Jan 9, 2012 at 9:15 PM, Steele, Richard <rich@steelezone.net> wrote:
> Yes, Spring and Blueprint are both installed as bundles--they're not in
> WEB-INF/lib so not on the application classloader.  We've set the weblogic
> classloading option to prefer loading from the war, so I doubt it's coming
> from weblogic (even if weblogic had it by default).  I can turn on the JVM
> verbose flag to double-check, though.
>
> As for what's going on, here's a step by step (assuming
> felix.service.urlhandlers is true):
>
> 1. The first EAR is deployed and the first instance of Felix is started.
> 2. URLHandlers.registerFrameworkInstance() is called the first time, which
> calls the URLHandlers() constructor.
> 3. The URLHandlers() constructor tries to call
> URL.setURLStreamHandlerFactory(this) but fails because weblogic has already
> installed its own.
> 4. The catch block starting at line 172 uses m_secureAction to
> do...something.  I'm not really sure what this is doing, but...
> 5. The test on line 185 is true because the original
> URLStreamHandlerFactory isn't one from Felix but the one from weblogic, so
> we install the new factory instance.
> 6. The second EAR is deployed with its new instance of Felix.
> 7. Same as #2.
> 8. Same as #3, this time failing because the Felix handler is already
> installed.
> 9. This time, the logic in the else if block at lines 190 through 201 runs,
> calling registerFrameworkListsForContextSearch(), which adds to the map
> m_classloaderToFrameworkLists.
>
> The trap, as such, is now set.  When getFrameworkFromContext() is called:
>
> 10. m_classloaderToFrameworkLists is not empty, because of #9 above.
> 11. The logic starting on line 600 runs.  It appears we're looking for a
> Felix-specific classloader, but the problem is we only find weblogic class
> loaders.  So, by the time we get to line 620 target class is null and we
> fall through to 663, returning null.

Yes, as I said in my previous mail: we forgot to adapt the logic to
the refactorings introduced in 4.0. Sorry - I was barking up the wrong
tree - your example should run and it is a bug that it doesn't. Please
create an issue to track it but I will provide a fix asap.

regards,

Karl

> In a nutshell that's how we end up with the "framework instance not found."
>
> Rich
>
> On Mon, Jan 9, 2012 at 2: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
>>
>> ---------------------------------------------------------------------
>> 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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message