Skip to main content



      Home
Home » Eclipse Projects » Virgo » Using config artifacts for multiple envs
Using config artifacts for multiple envs [message #798222] Tue, 14 February 2012 06:51 Go to next message
Eclipse UserFriend
Hello.

I am considering using Configuration Artifacts in order to define environment specific properties in several of my bundles.

However I am not clear about the mechanics. Do I need a separate plan file for each environment, each pointing to a configuration artifact that is specific to that environment?

If so, I would have to manually manage which plan file is deployed to which Virgo server (I have one per environment). Is this the intended practice?

Or can I make things more transparent and dynamic?

TIA,
B.
Re: Using config artifacts for multiple envs [message #798356 is a reply to message #798222] Tue, 14 February 2012 10:25 Go to previous messageGo to next message
Eclipse UserFriend
You could do what you describe. An alternative would be to configure each Virgo instance with its own initialArtifacts property -- described in the User Guide -- pointing to the relevant properties file. Then the configuration would be available before the bundles which refer to it.
Re: Using config artifacts for multiple envs [message #799088 is a reply to message #798356] Wed, 15 February 2012 07:33 Go to previous messageGo to next message
Eclipse UserFriend
Thanks Glyn.

I am trying the approach out, but I get the following exception at runtime:
[2012-02-15 12:28:40.176] region-dm-9                  <AG0000E> Application context creation failure for bundle 'com.iggroup.wb.core.sso' version '1.0.0.SNAPSHOT'. org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 87 in XML document from URL [bundleentry://85.fwk1260137319/META-INF/spring/core.sso-osgi-context.xml] is invalid; nested exception is org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name 'osgi:TbaseService' to a(n) 'type definition' component.
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:396)
	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.springframework.osgi.context.support.OsgiBundleXmlApplicationContext.loadBeanDefinitions(OsgiBundleXmlApplicationContext.java:164)
	at org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext.loadBeanDefinitions(OsgiBundleXmlApplicationContext.java:136)
	at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:130)
	at org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:467)
	at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.access$800(AbstractDelegatedExecutionApplicationContext.java:69)
	at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$3.run(AbstractDelegatedExecutionApplicationContext.java:269)
	at org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85)


The declarations in the spring config files are as follows:
<context:property-placeholder properties-ref="configAdminProperties"/>


and
<osgi-compendium:cm-properties id="configAdminProperties" persistent-id="core.sso-properties" />


with the schema and namespace declaration as follows:
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:osgi="http://www.springframework.org/schema/osgi"
	xmlns:util="http://www.springframework.org/schema/util"
	xmlns:osgi-compendium="http://www.springframework.org/schema/osgi-compendium"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
		http://www.springframework.org/schema/osgi http://www.springframework.org/schema/osgi/spring-osgi-1.1.xsd
		http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-3.0.xsd
		http://www.springframework.org/schema/osgi-compendium 
    	http://www.springframework.org/schema/osgi-compendium/spring-osgi-compendium.xsd">


Please note that I have the two declarations above (<osgi-compendium:cm-properties id="configAdminProperties" persistent-id="core.sso-properties" /> and <context:property-placeholder properties-ref="configAdminProperties"/> in two separate spring config files.

I am also using version 3.0.5 of the Spring Framework and Virgo 3.0.0.RELEASE.

Ideas?

TIA,
B.

[Updated on: Wed, 15 February 2012 07:36] by Moderator

Re: Using config artifacts for multiple envs [message #799209 is a reply to message #799088] Wed, 15 February 2012 11:05 Go to previous messageGo to next message
Eclipse UserFriend
Ok, the error above is now solved. I have placed the two declaration next to each other in the same config file and the exception disappears.

However the properties file does not seem to be read correctly and I now have a fundamental question: does the configuration artifacts mechanism work for Virgo Kernels as well or only for full blown Virgo Web servers?
Re: Using config artifacts for multiple envs [message #799220 is a reply to message #799209] Wed, 15 February 2012 11:14 Go to previous messageGo to next message
Eclipse UserFriend
Configuration artifacts are a kernel feature.
Re: Using config artifacts for multiple envs [message #799266 is a reply to message #799220] Wed, 15 February 2012 12:18 Go to previous messageGo to next message
Eclipse UserFriend
Thanks Glyn, that at least is comforting.

I have been trawling through the trace log and everything seems in order, but my property files are not being read. My plan contains a number of bundles, two of which need configuration artifacts.

So my plan lists all bundles and the two configuration artifacts pointing to the right property files. One of the properties is the serviceUrl string for a server JMX MBean that is created and registered when the bundle is activated.

At runtime no errors at all are generated and, as I said, the trace file indicates all is ok, but the MBean keeps on being exposed on the default port instead of my custom one that is defined in the properties file.
Re: Using config artifacts for multiple envs [message #799309 is a reply to message #799266] Wed, 15 February 2012 13:23 Go to previous messageGo to next message
Eclipse UserFriend
Just to test the config artifacts mechanism, I have tried adding a property to a bean in another bundle, using a placeholder had the config artifact as per the manuals, and it all works like a charm.

Therefore I am led to believe that the issue is specific to the creation of the JMX MBean, perhaps a lifecycle issue. Is it possible that the bean is published on the default RMI port BEFORE Virgo has a chance to to the variable susbtitution?
Re: Using config artifacts for multiple envs [message #799850 is a reply to message #799309] Thu, 16 February 2012 06:33 Go to previous message
Eclipse UserFriend
Moving conversation to more appropriately titled (and phrased Smile thread http://www.eclipse.org/forums/index.php/t/292557/
Previous Topic:Spring Security on multiple bundles
Next Topic:Virgo 3.5.0.M02 released
Goto Forum:
  


Current Time: Mon May 12 21:43:23 EDT 2025

Powered by FUDForum. Page generated in 0.04452 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top