Hi Tim, The reason for the property override configurator is to allow end users who download an exported binary of the application to be able to modify its configuration without having to unpack and repack jars. For example all my bundles will point to this override configurator which allows the user to put a single properties file in the base directory of the application and override any configuration properties that have been exposed to them. As an example if your application listened on port 8080 and you wanted to easily override it to start listening on port 80. It could also potentially be useful at test time, although fragments may be sufficient there, I'm not sure what the semantics of overriding Blueprint files with fragments is.
I also have some questions about performance, has there been any benchmarking comparisons between Aries and Spring DM/Gemini? Particularly would you ever dare wire together something that needs toe be called a lot and is performance sensitive using services managed by Aries? I'm looking at a stack trace of a bean that has had an OSGi service wired in to it from another bundle using Spring DM, and called a method on that bean, and there are 22 method invocations between the source and when it actually hits the method across a ton of proxies, advice, interceptors, etc, which to me seems quite excessive. Thanks, David On Wed, Jan 5, 2011 at 3:02 AM, Timothy Ward <[email protected]> wrote: > > Hi David, > > Your xml file is pretty simple to convert to standard blueprint: > > <?xml version="1.0" encoding="UTF-8"?> > <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> > > <bean id="myBean" class="foo.MyBean" > init-method="startUp" destroy-method="shutDown"> > <property name="ordering"> > <map> > <entry key="BAR" value="1,2,3,4,5"/> > </map> > </property> > <property name="dependentService" ref="dependentService"/> > </bean> > > <service id="myBean" ref="myBean" interface="foo.IMyBean"> > </service> > > <reference id="dependentService" availability="mandatory" > interface="foo.IService"> > </reference> > </beans> > The one caveat is that there is no standard version of the Spring specific > configuration override: > > <bean > class="org.springframework.beans.factory.config.PropertyOverrideConfigurer"> > <property name="ignoreResourceNotFound" value="true" /> > <property name="locations" value="file:./my.properties"/> > </bean> > > We could theoretically add something like this to the Aries blueprint > implementation, but it would still be implementation specific. If you can > give us some > use cases we could start to work on it and see about feeding it back into the > blueprint specification, however at the moment I can't see what problem it is > trying to solve... > > Regards, > > Tim > > ---------------------------------------- >> Date: Tue, 4 Jan 2011 15:00:20 -0800 >> Subject: Re: Aries interop with Spring? >> From: [email protected] >> To: [email protected] >> >> On Tue, Dec 28, 2010 at 2:09 AM, Guillaume Nodet wrote: >> > Spring-DM and Aries Blueprint (and other technologies such as SCR or >> > iPojo) are fully interopable through the use of the OSGi registry. >> >> Thanks for the replies. Just so I feel fully clear on the subject, >> lets assume I have the following xml file: >> >> >> >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >> xmlns:util="http://www.springframework.org/schema/util"; >> xmlns:bp="http://www.osgi.org/xmlns/blueprint/v1.0.0"; >> xsi:schemaLocation="http://www.springframework.org/schema/beans >> http://www.springframework.org/schema/beans/spring-beans-3.0.xsd >> http://www.springframework.org/schema/util >> http://www.springframework.org/schema/util/spring-util-3.0.xsd >> http://www.osgi.org/xmlns/blueprint/v1.0.0 >> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd";> >> >> >> >> >> >> >> >> init-method="startUp" destroy-method="shutDown"> >> >> >> >> >> >> >> >> >> >> >> >> >> interface="foo.IService"> >> >> >> >> Can I take Spring + Aries and have the above just work? What I am >> wondering is because Spring itself is not OSGi aware, who handles >> finding the code that handles the declared namespaces, and ends up >> creating the Spring container, and handling the interaction between it >> and the service registry, is this Aries? Is there a standard that has >> been developed for dealing with IoC containers and these namespaces? >> I guess I am wondering if Aries has to have Spring specific code in >> here to do this, or if its been standardized in a manner so that >> everything 'just works' now. >> >> Thanks, >> David >
