Hi David, There should be a copy of the RFC draft available here: http://www.osgi.org/download/osgi-4.2-early-draft3.pdf
You will be after section 5.7.1 Property Placeholder Support of RFC 124 (page 259 of the PDF). Regards, Tim ---------------------------------------- > Date: Sat, 8 Jan 2011 00:00:54 -0800 > Subject: Re: Aries interop with Spring? > From: halcyon1...@gmail.com > To: user@aries.apache.org > > Hi Tim- > > On Thu, Jan 6, 2011 at 2:58 AM, Timothy Ward wrote: > > > > Hi David, > > > > From what you are describing it sounds as though the blueprint config admin > > integration would suit your needs. This was part of the original blueprint > > specification, but was not complete enough to be included in the 4.2 > > enterprise release. Aries has an implementation of what was in that > > specification draft, and it allows for the use of property-placeholder > > elements and default values. This sounds to be exactly what you get from > > the properties file. > > Sounds like I'll have to check this out, do you have a pointer? > > > > > One question I do have is the following - in an OSGi framework how is the > > properties file located if it isn't packaged inside the bundle? The OSGi > > classloading model will mean that the properties file is not visible unless > > it is packaged inside the bundle or specifically imported. This would seem > > to indicate that the properties file cannot be used without repacking the > > jars anyway. > > I expect it to be in the current working directory from where the app > was launched. > > Thanks! > David > > > > As for the speed of Aries, I'm afraid I don't have any numbers I can show > > you. Previous experience suggests our performance is at least as good as > > Gemini. We also have proxy layers, and the number of invocations will > > depend on what you configure, but 22 sounds pretty high. > > > > Regards, > > > > Tim > > > > > > > > ---------------------------------------- > >> Date: Wed, 5 Jan 2011 09:09:34 -0800 > >> Subject: Re: Aries interop with Spring? > >> From: halcyon1...@gmail.com > >> To: user@aries.apache.org > >> > >> 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 wrote: > >> > > >> > Hi David, > >> > > >> > Your xml file is pretty simple to convert to standard blueprint: > >> > > >> > > >> > > >> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> > >> > > >> > > >> > init-method="startUp" destroy-method="shutDown"> > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > interface="foo.IService"> > >> > > >> > > >> > The one caveat is that there is no standard version of the Spring > >> > specific configuration override: > >> > > >> > > >> > > >> > > >> > > >> > > >> > 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: halcyon1...@gmail.com > >> >> To: aries-u...@incubator.apache.org > >> >> > >> >> 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 > >> > > >
