Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Gemini » Blueprint: Namespace trouble
Blueprint: Namespace trouble [message #655502] Mon, 21 February 2011 08:30 Go to next message
Thomas Kratz is currently offline Thomas Kratz
Messages: 163
Registered: July 2009
Senior Member
HI, I'm trying to set up blueprint inside of e4. Some progress so far but when it loads my spring config I get strange namespace handler errors:
ERROR org.eclipse.gemini.blueprint.extender.internal.activator.ContextLoaderListener Application context refresh failed (OsgiBundleXmlApplicationContext(bundle=de.eiswind.mango.client.core, config=osgibundle:/META-INF/spring/*.xml))
org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.springframework.org/schema/context]
Offending resource: URL [bundleentry://67.fwk1582031564/META-INF/spring/beans-context.xml]

	at org.springframework.beans.factory.parsing.FailFastProblemReporter.error(FailFastProblemReporter.java:68)
	at org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:85)
	at org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:80)
	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.error(BeanDefinitionParserDelegate.java:284)
	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1332)
	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1325)
	at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:135)
	at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:93)
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493)
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:334)
	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(Unknown Source)
ERROR org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor Unable to create application context for [de.eiswind.mango.client.core], unsatisfied dependencies: none
org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.springframework.org/schema/context]
Offending resource: URL [bundleentry://67.fwk1582031564/META-INF/spring/beans-context.xml]

	at org.springframework.beans.factory.parsing.FailFastProblemReporter.error(FailFastProblemReporter.java:68)
	at org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:85)
	at org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:80)
	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.error(BeanDefinitionParserDelegate.java:284)
	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1332)
	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1325)
	at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:135)
	at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:93)
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493)
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:334)
	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(Unknown Source)



my context goes like
<?xml version="1.0" encoding="UTF-8"?>
<beans 	xmlns="http://www.springframework.org/schema/beans" 
		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
		xmlns:context="http://www.springframework.org/schema/context" 
		xmlns:osgi="http://www.springframework.org/schema/osgi"
	xsi:schemaLocation="http://www.springframework.org/schema/beans
      http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
      http://www.springframework.org/schema/context
      http://www.springframework.org/schema/context/spring-context-2.1.xsd
      http://www.springframework.org/schema/osgi
       http://www.springframework.org/schema/osgi/spring-osgi.xsd
      ">

	

	<context:property-placeholder location="classpath:dummy.properties"/>
	 
	 <osgi:service ref="serviceCache" interface="de.eiswind.paris.client.core.services.IServiceCache"/>

	<bean id="abstractProxy" class="org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean" abstract="true">
		<property name="httpInvokerRequestExecutor">
			<bean class="org.springframework.remoting.httpinvoker.CommonsHttpInvokerRequestExecutor" />
		</property>
	</bean>
... more beans here


Can anypone give me a hint waths wrong with that ?
I tried the spring forums, but the answers didn't get my any further.
Re: Blueprint: Namespace trouble [message #655561 is a reply to message #655502] Mon, 21 February 2011 13:52 Go to previous messageGo to next message
Mathieu Baudier is currently offline Mathieu Baudier
Messages: 5
Registered: December 2010
Location: Berlin
Junior Member

Is this configuration working with another approach, like say, Spring DM?

In the namespace declarations:

      http://www.springframework.org/schema/beans
      http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
      http://www.springframework.org/schema/context
      http://www.springframework.org/schema/context/spring-context-2.1.xsd


Maybe you should try with:

      http://www.springframework.org/schema/context
      http://www.springframework.org/schema/context/spring-context.xsd


or

      http://www.springframework.org/schema/context
      http://www.springframework.org/schema/context/spring-context-3.0.xsd


Usually the namespace XSDs are in the Spring JARs of the related version, registered with both no version and the current version of Spring.

DISCLAIMER: I have no experience with Blueprint or Spring 3.0, I just quickly answer based on my general experience with Spring (2.x), in case this may by chance solve your problem.
Maybe it has absolutely nothing to do with that...
Re: Blueprint: Namespace trouble [message #655581 is a reply to message #655502] Mon, 21 February 2011 14:42 Go to previous messageGo to next message
David Fogel is currently offline David Fogel
Messages: 1
Registered: February 2011
Junior Member
Like the last poster pointed out, it does seem like you could clean up your namespace declarations.

However, I've had something similar happen in our project (using raw spring DM in equinox), and for us it's a weird, _intermittent_ issue where our app will just fail to start a few times, throwing this same exception, and then finally it will work again. I looked at this in depth a few months back (and I found dozens of useless forum posts with people having similar issues), and although I frustratingly can't remember all the details, I think there's a race condition somewhere such that if the wrong classloader gets checked for the namespace XSD files before the right one is there, then this happens.

Anyhow, my point is that if your project reliably fails with this message, it may be a simple configuration problem, but if it fails sometimes and works other times, then I think you're hitting what we ran into, and I would look at bundle start orderings and that sort of thing.
Re: Blueprint: Namespace trouble [message #655666 is a reply to message #655581] Tue, 22 February 2011 04:05 Go to previous messageGo to next message
Thomas Kratz is currently offline Thomas Kratz
Messages: 163
Registered: July 2009
Senior Member
It was completely reproducable, and I found a post in the spring forums that sounded like the same trouble. I stepped back on dm 1.2 and that works fine.
Re: Blueprint: Namespace trouble [message #655676 is a reply to message #655502] Tue, 22 February 2011 04:39 Go to previous messageGo to next message
Mathieu Baudier is currently offline Mathieu Baudier
Messages: 5
Registered: December 2010
Location: Berlin
Junior Member

Did you try changing the namespaces definitions?

Do you have a link to the other forum post?

We will soon start moving to Blueprint and we use namespaces massively, so your problem is a bit worrying...
Re: Blueprint: Namespace trouble [message #655678 is a reply to message #655676] Tue, 22 February 2011 04:42 Go to previous messageGo to next message
Thomas Kratz is currently offline Thomas Kratz
Messages: 163
Registered: July 2009
Senior Member
Yes I used the namespace urls from the jars, and sorry I don't remember the link, it was not of help though. Only found that someone had the same problem.
Re: Blueprint: Namespace trouble [message #681996 is a reply to message #655678] Fri, 10 June 2011 03:51 Go to previous messageGo to next message
Costin Leau is currently offline Costin Leau
Messages: 45
Registered: February 2010
Member
It's a problem regarding the way the bundles presenting namespaces work - in 1.2 we used bundles in RESOLVED state, in 2.0 we changed to that STARTED. To cope with both parties, I'm working on introducing a flag to enable both behaviours and switching the default to RESOLVED.
Re: Blueprint: Namespace trouble [message #682079 is a reply to message #681996] Fri, 10 June 2011 07:19 Go to previous messageGo to next message
Chetan Mising name is currently offline Chetan Mising name
Messages: 4
Registered: February 2011
Junior Member
Can you provide some details on what difference it makes on using Namespace Handler from a Bundle in resolved state or in start state

To solve the same problem in our app (based on Felix) I had to change the StartLevel for Extender Bundle to a higher value than other Spring related Bundles
Re: Blueprint: Namespace trouble [message #696151 is a reply to message #681996] Wed, 13 July 2011 07:34 Go to previous messageGo to next message
Stefan Missing name is currently offline Stefan Missing name
Messages: 4
Registered: July 2011
Junior Member
Hallo Costin,
thank you for updating your release plan!

I am working with 1.0.0.M1 for months an was not able to fix/work around the namespace bug.

First testing of RC1 did not make any difference...

I am testing with two environments:
* pax-runner 1.5.0 with Equinox 3.6.0xyz (all bundles auto-start=true)
* Eclipse 3.6 PDE

With Pax, the situation never appears.

With PDE, I encounter random startup problems. PDE seams to keep some internal state between restarts; thus the problem persists for many restarts until a significant modification in the launch configuration occurs.

btw. how is this problem related to bug 351307 ?

Thanks in advance for any hint!

regards
Stefan
Re: Blueprint: Namespace trouble [message #696231 is a reply to message #682079] Wed, 13 July 2011 10:39 Go to previous messageGo to next message
Stefan Missing name is currently offline Stefan Missing name
Messages: 4
Registered: July 2011
Junior Member
Hello,

Chetan wrote on Fri, 10 June 2011 13:19
Can you provide some details on what difference it makes on using Namespace Handler from a Bundle in resolved state or in start state

To solve the same problem in our app (based on Felix) I had to change the StartLevel for Extender Bundle to a higher value than other Spring related Bundles


this workaround did it for me in my PDE environment!

extender: level=6

Re: Blueprint: Namespace trouble [message #718100 is a reply to message #696231] Tue, 23 August 2011 05:04 Go to previous messageGo to next message
Costin Leau is currently offline Costin Leau
Messages: 45
Registered: February 2010
Member
We had a bug that affected the discovery of namespaces available in bundles already installed before the extender. This has been fixed in the GA/official release - check it out!
Re: Blueprint: Namespace trouble [message #947655 is a reply to message #718100] Wed, 17 October 2012 05:39 Go to previous message
Sebastian Lorenz is currently offline Sebastian Lorenz
Messages: 36
Registered: November 2010
Member
Using Blueprint 1.0.2.Release I still get this error if my persistence bundles get restarted at application startup. If I disable bundle refresh with -DREFRESH_BUNDLES=false the error is gone.

Okt 17, 2012 11:21:28 AM org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor fail
Schwerwiegend: Unable to create application context for [com.qualitype.personmanager], unsatisfied dependencies: none
org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http\://www.springframework.org/schema/osgi]
Offending resource: URL [bundleentry://117.fwk1823840336/META-INF/spring/config.xml]

	at org.springframework.beans.factory.parsing.FailFastProblemReporter.error(FailFastProblemReporter.java:68)
	at org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:85)
	at org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:80)
	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.error(BeanDefinitionParserDelegate.java:316)
	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1416)
	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1409)
	at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:184)
	at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.doRegisterBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:140)
	at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:111)
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493)
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:334)
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:302)
	at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:174)
	at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:209)
	at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:180)
	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:131)
	at org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:522)
	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:211)
	at java.lang.Thread.run(Unknown Source)


Btw: In the error message I added a backslash in the namespace cause I'm not allowed to use links in this forum.

[Updated on: Wed, 17 October 2012 05:41]

Report message to a moderator

Previous Topic:org.eclipse.gemini.jpa.test.common fails to build because of DataSourceFactory
Next Topic:[Solved]Issue with Gemini - "Object is not a known Entity Type"
Goto Forum:
  


Current Time: Thu Aug 21 16:10:51 EDT 2014

Powered by FUDForum. Page generated in 0.02536 seconds