Can you include scanning services or certain types of annotated services to
inject camel things into? That way you can use DS components more easily.
On 1 August 2016 at 20:03, Brad Johnson <brad.john...@mediadriver.com>
wrote:
> The CamelContext disambiguation obviously is a next step...
>
> On Mon, Aug 1, 2016 at 8:01 PM, Brad Johnson <brad.john...@mediadriver.com
> > wrote:
>
>> I'd thought that it was possible since the examples have a SimpleRegistry
>> and mention using it to register beans. But when I looked at the
>> AbstractCamelRunner it became obvious that that would not work.
>>
>> I'm trying something by creating a new SCRRegistry type just for the
>> sake of experimentation. Internally it has a CompositeRegistry and the
>> AbstractCamelRunner which I'm modifying uses the new SCRRegistry which has
>> a setter or on it for both a SimpleRegistry and an OsgiRegistry. If it
>> finds the bundle context it creates the OSGi service registry and adds it
>> and in either case adds a SimpleRegistry after it.
>>
>>
>> protected void createCamelContext(final BundleContext bundleContext,
>> final Map<String, String> props) {
>> if (bundleContext != null) {
>> OsgiServiceRegistry osgiRegistry = new
>> OsgiServiceRegistry(bundleContext);
>> context = new OsgiDefaultCamelContext(bundleContext,
>> osgiRegistry);
>> // Setup the application context classloader with the bundle
>> classloader
>> context.setApplicationContextClassLoader(new
>> BundleDelegatingClassLoader(bundleContext.getBundle()));
>> // and make sure the TCCL is our classloader
>>
>> Thread.currentThread().setContextClassLoader(context.getApplicationContextClassLoader());
>> this.registry.setOsgiRegistry(osgiRegistry);
>> }
>> registry.setSimpleRegistry(new SimpleRegistry());
>> context = new DefaultCamelContext(registry);
>>
>>
>>
>> Inside the SCRRegistry it delegates all its Registry interface calls to
>> the CompositeRegistry but it keeps a handle on the SimpleRegistry. So to
>> register a class one can do the following:
>>
>> registry.register(POValidator.class);
>>
>> In this case it's very simple instantiation of the no-arg constructor and
>> then looking for EndpointInject annotations and setting it to the
>> ProducerTemplate and the URI it finds. This is such a quick and naive cut
>> that I'm not even checking to see if there's an endpoint by that name in
>> the registry already which I could just use instead. Obviously if I do
>> anything more with this I'll look at reusing the existing libraries for
>> annotation processing instead of writing this stuff by hand. I still
>> haven't tested this by throwing it in karaf with Felix or any other OSGi
>> implementation.
>>
>> public void register(Class clazz){
>> try {
>> Object o=clazz.newInstance();
>> for(Field declaredField:clazz.getDeclaredFields())
>> {
>> for(EndpointInject endpoint:
>> declaredField.getAnnotationsByType(EndpointInject.class))
>> {
>> declaredField.setAccessible(true);
>> ProducerTemplate template = camelContext.createProducerTemplate();
>> template.setDefaultEndpointUri(endpoint.uri());
>> declaredField.set(o,template);
>> }
>> }
>> this.simpleRegistry.put(clazz.getSimpleName(), o);
>> } catch (InstantiationException | IllegalAccessException e) {
>> //TODO log..
>> }
>> }
>>
>> On Mon, Aug 1, 2016 at 6:33 PM, Matt Sicker <boa...@gmail.com> wrote:
>>
>>> Can you even make a semi-private service in DS/SCR? What could the
>>> equivalent be to a blueprint bean that isn't exported as a service? Or is
>>> the philosophy to make all services public in DS?
>>>
>>> On 1 August 2016 at 18:12, Brad Johnson <brad.john...@mediadriver.com>
>>> wrote:
>>>
>>>> Tim,
>>>>
>>>> After working with DS and SCR a little I can understand its benefits.
>>>> One obvious advantage was being able to write basic JUnit tests to test my
>>>> routes without having to fire up CBTS. I've always disliked working in XML
>>>> so it is odd being in the position like I sound like I'm the one
>>>> championing it.
>>>>
>>>> The main problem right now with Camel is that while SCR handles all the
>>>> external items there isn't a way to do any injection of "local"
>>>> dependencies. By that I mean within my own bundle I might have validators,
>>>> handlers, local data models, etc. that I want to stand up and run in my
>>>> Camel routes. Camel SCR doesn't have a mechanism for doing that.
>>>>
>>>> When one runs it locally in the IDE it fires up a SimpleRegistry and
>>>> uses that to register everything and in that case you can manually add your
>>>> own beans before setting up route definitions. If the bundle is running
>>>> where it has a bundle context it instead fires up an
>>>> OsgiServiceRegistry(don't recall the full name.) In that case you can't add
>>>> your local beans.
>>>>
>>>> I noted that there is a CompositeRegistry in the AbstractCamelRunner
>>>> and perhaps that should always be the one used. If one boots up and an
>>>> OSGi service registry is created both it and the SimpleRegistry are added
>>>> to the CompositeRegistry but one can access the SimpleRegistry in order to
>>>> add one's local dependencies for Camel routes.
>>>>
>>>> On Wed, Jul 13, 2016 at 3:34 AM, Timothy Ward <timothyjw...@apache.org>
>>>> wrote:
>>>>
>>>>> Hi Brad,
>>>>>
>>>>> I’ve been watching this thread for a while, and you’ve finally managed
>>>>> to draw me in :)
>>>>>
>>>>>
>>>>> On 12 Jul 2016, at 17:42, Brad Johnson <brad.john...@mediadriver.com>
>>>>> wrote:
>>>>>
>>>>> Guillaume,
>>>>>
>>>>> I'm still using Blueprint and have found Camel/SCR to be a pain to
>>>>> work with. It provides no tangible benefit if one is using Blueprint for
>>>>> routes and dependency injection anyway as it simply introduces one more
>>>>> way
>>>>> of configuring things. It was interesting to read the other day that
>>>>> Christian seems to have the same impression of the complexity of SCR. I
>>>>> remember when I first tried I thought it looked pretty cool but started
>>>>> running into problems.
>>>>>
>>>>>
>>>>> So what you’re comparing here isn’t really apples with apples. A long
>>>>> way back Camel provided a bunch of Spring XML sugar to make configuring
>>>>> Camel simpler. This was obviously a good thing because setting up Camel
>>>>> was
>>>>> (and is) hard. To this day people still use the Spring syntax for building
>>>>> their Camel routes. OSGi blueprint was effectively a move by Spring to
>>>>> standardise the Spring DM container, and so unsurprisingly blueprint looks
>>>>> a lot like Spring. Some people did the work to port the Camel Spring
>>>>> configuration to OSGi blueprint, and that’s why Camel is easy to use in
>>>>> blueprint.
>>>>>
>>>>> If someone actually spent some time putting together a nice
>>>>> integration with SCR then I’m sure that using SCR would be at least as
>>>>> easy
>>>>> as blueprint. The problem here is that relatively few SCR developers/users
>>>>> use Camel, and the ones that do are just told to “use blueprint”.
>>>>>
>>>>> That DS is in its second generation and only now getting around to
>>>>> transactions is telling. Either it has reached its natural boundaries and
>>>>> is now over-reaching or wasn’t full thought out.
>>>>>
>>>>>
>>>>> DS is actually working on its fifth release, and transactions are
>>>>> nowhere to be seen. You may be referring to the Transaction Control
>>>>> specification, which is separate from DS. They can be used together very
>>>>> effectively, but you could equally use Transaction Control with blueprint.
>>>>>
>>>>> DS is actually one of the “good citizens” of the DI world in that it
>>>>> deliberately does less in order to do it well. There’s no dependency
>>>>> proxying, no aspects, just the code that you wrote injected with some
>>>>> other
>>>>> code that someone wrote.
>>>>>
>>>>> To me it's a component and service bootstrapping mechanism which
>>>>> represents a small portion of the world I work in - transforms, routing,
>>>>> EIPs, etc. I've no reason to embrace it or deny it unless it either makes
>>>>> my job much easier or I can't live without it. So far adding Camel SCR
>>>>> and
>>>>> DS into the middleware just results in one more thing I have to deal with.
>>>>>
>>>>>
>>>>> This is a perfectly acceptable viewpoint. If the fundamental
>>>>> limitations of the blueprint model aren’t a problem for you then switching
>>>>> right now is almost certainly unnecessary.
>>>>>
>>>>>
>>>>> I think Blueprint works well these days and has come a long way in the
>>>>> past 3 years. The Aries team is to be commended for some great work.
>>>>>
>>>>>
>>>>> Aries Blueprint has had a lot of extensions and improvements over the
>>>>> last three years. Sadly the same cannot be said for the specifications or
>>>>> other implementations. Aries Blueprint is very much the last
>>>>> implementation
>>>>> standing, and there has been no effort to standardise the new features (or
>>>>> even to try fixing the problems with the original standard). The set of
>>>>> RFPs/RFCs for blueprint that have been sitting idle in the OSGi Alliance
>>>>> is
>>>>> very telling.
>>>>>
>>>>> As far as Aries blueprint is concerned, the main reason that it is
>>>>> still alive seems to be the fact that it was included in Karaf, and that
>>>>> Karaf provides Camel integration alongside it. Even Karaf itself is
>>>>> starting to move to use DS internally, offering blueprint as something for
>>>>> applications to use.
>>>>>
>>>>>
>>>>> I’ve been surprised by the near religious zeal of some of the DS
>>>>> advocates.
>>>>>
>>>>>
>>>>> Most OSGi developers I know (myself included) who really start to use
>>>>> DS consider it to be roughly equivalent to magic. The fact that the model
>>>>> can be as simple as it is and yet still flexible, correct and safe is both
>>>>> surprising and pleasing. Moving back to “not DS” is usually pretty painful
>>>>> and reminds people why they love DS so much.
>>>>>
>>>>> I'll be interested in seeing the DS semantics and proxies for CDI.
>>>>> Heh. Proxies are another technology that I don't care about one way or the
>>>>> other as long as things work well and don't require a lot of
>>>>> configuration. So it’s great if we can get rid of proxies but not so
>>>>> great
>>>>> if I now have to trade that off for configuration of start up order on
>>>>> services to make sure everything is running before Camel routes come up.
>>>>>
>>>>>
>>>>> Actually, this is one of the places where DS really shines. If you
>>>>> write a DS component properly (i.e. without trying to dig out of the DS
>>>>> lifecycle) then startup ordering ceases to be an issue.
>>>>>
>>>>> Again, someone with a little time and expertise would probably find
>>>>> that Camel + DS can be a really effective solution. The problem is finding
>>>>> the person who has the time, expertise and inclination…
>>>>>
>>>>> Tim Ward
>>>>>
>>>>> Apache Aries PMC Member,
>>>>> OSGi IoT Expert Group Chair,
>>>>> Author Enterprise OSGi in Action
>>>>> timothyjw...@apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jul 12, 2016 at 10:57 AM, Guillaume Nodet <gno...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> I can happily review a patch if you're fancy writing one...
>>>>>>
>>>>>> And I disagree with the 'blueprint is dead and nobody cares about it
>>>>>> anymore'. What's dead is the blueprint osgi specification for blueprint,
>>>>>> not the Aries Blueprint project. I've recently added a bunch of
>>>>>> important
>>>>>> features related to spring in blueprint.
>>>>>>
>>>>>> DS also has some drawbacks as it's not extensible at all : this is
>>>>>> leading the OSGi Alliance to write a new spec for transaction support !!!
>>>>>>
>>>>>> I think the CDI+DS extension I've been working on those past weeks
>>>>>> could bring the best of both world : strong DS semantics for the OSGi
>>>>>> bits,
>>>>>> but extensibility and support for proxies provided by CDI ;-)
>>>>>>
>>>>>>
>>>>>> 2016-07-12 17:24 GMT+02:00 Brad Johnson <brad.john...@mediadriver.com
>>>>>> >:
>>>>>>
>>>>>>> David,
>>>>>>>
>>>>>>> I'm all for multilocation support in blueprint. Can't wait for it.
>>>>>>> But it sounds like your saying blueprint is dead and nobody cares
>>>>>>> about
>>>>>>> it anymore so it doesn't seem likely to happen anytime soon. It
>>>>>>> certainly
>>>>>>> wouldn't be relevant to Fuse which uses R4 in any case.
>>>>>>>
>>>>>>> On Tue, Jul 12, 2016 at 10:21 AM, Brad Johnson <
>>>>>>> brad.john...@mediadriver.com> wrote:
>>>>>>>
>>>>>>>> The features file can have statements like this:
>>>>>>>>
>>>>>>>>
>>>>>>>> <configfile finalname="/etc/com.foo.cfg"
>>>>>>>> override="true">mvn:com.confignuration/myrpoject/${project.version}/cfg/com.foo</configfile>
>>>>>>>> <configfile finalname="/etc/com.bar.cfg"
>>>>>>>> override="true">mvn:comconfiguration/myproect/${project.version}/cfg/com.bar</configfile>
>>>>>>>> ....etc....
>>>>>>>> That's off the top of my head so take it with a grain of salt for
>>>>>>>> syntax.
>>>>>>>>
>>>>>>>> When you run the features install it will overwrite the files in
>>>>>>>> the etc directory with the ones in the maven bundle which have now been
>>>>>>>> updated. So instead of modifying configuration files in the etc
>>>>>>>> directory
>>>>>>>> you modifying them in your Maven configuration project and recompile
>>>>>>>> the
>>>>>>>> bundle and then pull it from the repo
>>>>>>>> in order to update the values.
>>>>>>>>
>>>>>>>> But you can still modify them in the etc if you wanted. You just
>>>>>>>> have to make sure you have the cm properties set to reload.
>>>>>>>>
>>>>>>>> <cm:property-placeholder persistent-id="com.foo"
>>>>>>>> update-strategy="reload">
>>>>>>>>
>>>>>>>> On Tue, Jul 12, 2016 at 9:45 AM, Pablo Gómez Pérez <
>>>>>>>> pablo.go...@faw.jku.at> wrote:
>>>>>>>>
>>>>>>>>> Brad, if I understand your approach too that would lead to not
>>>>>>>>> being able to dynamically change common properties in a single config
>>>>>>>>> place
>>>>>>>>> during runtime, as the fill made by maven would be only done once at
>>>>>>>>> build
>>>>>>>>> time right? But at runtime I would need to that as David mention,
>>>>>>>>> still n
>>>>>>>>> times right?
>>>>>>>>>
>>>>>>>>> as a use case for instance, with blueprint:cm update-strategy
>>>>>>>>> configured as 'reload' in combination with felix-fileinstall as
>>>>>>>>> directory
>>>>>>>>> watcher, bundles are reloaded automatically so that when I modify at
>>>>>>>>> anytime during runtime a property e.g with just a text editor the
>>>>>>>>> bundle is
>>>>>>>>> initiated again with the new property values which is a quite nice
>>>>>>>>> feature
>>>>>>>>>
>>>>>>>>> best
>>>>>>>>>
>>>>>>>>> Pablo
>>>>>>>>>
>>>>>>>>> On 12/07/2016 12:31 AM, David Jencks wrote:
>>>>>>>>>
>>>>>>>>> I’d like to make sure I understand what you are doing here…. IIUC
>>>>>>>>> during the build of your project you are generating multiple
>>>>>>>>> configuration
>>>>>>>>> files with the same or similar content, and each of these is loaded
>>>>>>>>> into a
>>>>>>>>> configuration which is bound to a particular bundle location? So, at
>>>>>>>>> build
>>>>>>>>> time you can change all the duplicate properties at once but if you
>>>>>>>>> need to
>>>>>>>>> change them later you have to alter n (== number of duplicate configs)
>>>>>>>>> independently? Whereas if you had multi-location support (and
>>>>>>>>> possibly
>>>>>>>>> multi-pid support such as DS provides) you could share a single
>>>>>>>>> Configuration and change the property while the framework was running
>>>>>>>>> in
>>>>>>>>> one place?
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>> On Jul 11, 2016, at 1:42 PM, Brad Johnson <
>>>>>>>>> brad.john...@mediadriver.com> wrote:
>>>>>>>>>
>>>>>>>>> Pablo,
>>>>>>>>>
>>>>>>>>> One possible solution to this problem that I'm currently looking
>>>>>>>>> at is using a configuration bundle along with my features bundle. In
>>>>>>>>> the
>>>>>>>>> configuration bundle I have all the cfg files and use properties
>>>>>>>>> placeholders ${value} to set the value for key/value.
>>>>>>>>>
>>>>>>>>> In the POM I load properties files using the Maven properties
>>>>>>>>> plugin and that lets me set a global set of properties values that
>>>>>>>>> can be
>>>>>>>>> used in filling in the cfg values. So if a port or URI is shared
>>>>>>>>> across a
>>>>>>>>> large number of them that automatically gets filled in. The features
>>>>>>>>> file
>>>>>>>>> can then specify the cfg files to install and what name to install
>>>>>>>>> them
>>>>>>>>> with.
>>>>>>>>>
>>>>>>>>> This gets rid of a lot of tedium and by using profiles I should be
>>>>>>>>> able to switch dev, test and production, and have the properties
>>>>>>>>> automatically set correctly.
>>>>>>>>>
>>>>>>>>> I'd like to modify this a bit so that dev, test and product cfg
>>>>>>>>> files are all created simultaneously and simply installed in different
>>>>>>>>> directories inside the configuration bundle. Then by using different
>>>>>>>>> features installs I can easily switch between the different
>>>>>>>>> configurations
>>>>>>>>> without having to tediously edit each configuration file.
>>>>>>>>>
>>>>>>>>> Brad
>>>>>>>>>
>>>>>>>>> On Sat, Jul 9, 2016 at 11:32 AM, Matt Sicker <boa...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Does Camel/Fuse even support DS? I haven't found any
>>>>>>>>>> documentation saying otherwise. I've only found camel-scr which uses
>>>>>>>>>> Felix-specific annotations and not DS.
>>>>>>>>>>
>>>>>>>>>> On 7 July 2016 at 14:32, Brad Johnson <
>>>>>>>>>> brad.john...@mediadriver.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> David,
>>>>>>>>>>>
>>>>>>>>>>> That is some pretty extreme and wild speculation alright. How
>>>>>>>>>>> does one use blueprint to not use OSGi appropriately? In the 5
>>>>>>>>>>> years I've
>>>>>>>>>>> been consulting with Fuse/Karaf/OSGi and going to various clients
>>>>>>>>>>> not one
>>>>>>>>>>> of them used or uses DS. Not one. They all use bundles, services,
>>>>>>>>>>> and
>>>>>>>>>>> Camel with blueprint. The last time I worked with DS I didn't find
>>>>>>>>>>> it
>>>>>>>>>>> provided any serious advantage and added another layer that I'd
>>>>>>>>>>> have to
>>>>>>>>>>> teach my clients. Not that I wouldn't consider it or use it if I
>>>>>>>>>>> found a
>>>>>>>>>>> real advantage but I haven't.
>>>>>>>>>>>
>>>>>>>>>>> Red Hat is still shipping Karaf 2.x with Fuse so it is still in
>>>>>>>>>>> OSGi 4.x land much less 5 or 6.
>>>>>>>>>>>
>>>>>>>>>>> So for Camel are you using the Java DSL?
>>>>>>>>>>>
>>>>>>>>>>> Brad
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Jul 7, 2016 at 1:56 PM, David Jencks <
>>>>>>>>>>> david_jen...@yahoo.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I don’t think karaf is at osgi R4.2 any more, I suggest you
>>>>>>>>>>>> look at the osgi R5 or R6 config admin spec for “multi location”.
>>>>>>>>>>>>
>>>>>>>>>>>> You guys might be using blueprint every day, but there is no
>>>>>>>>>>>> OSGI spec work to keep it up to date or even specify obviously
>>>>>>>>>>>> necessary
>>>>>>>>>>>> features such as config admin integration. If blueprint is so
>>>>>>>>>>>> great why
>>>>>>>>>>>> aren’t the proponents keeping the spec related to current OSGI?
>>>>>>>>>>>> This is a
>>>>>>>>>>>> part of my, admittedly extreme, theory that use of blueprint is
>>>>>>>>>>>> related to
>>>>>>>>>>>> not wanting to make the app actually use osgi appropriately.
>>>>>>>>>>>>
>>>>>>>>>>>> And, the project I work on every day uses DS exclusively and
>>>>>>>>>>>> still finds plenty of ways to abuse osgi in all sorts of inventive
>>>>>>>>>>>> ways :-)
>>>>>>>>>>>>
>>>>>>>>>>>> david jencks
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Jul 7, 2016, at 11:11 AM, Johan Edstrom <seij...@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> It is in here;
>>>>>>>>>>>> https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html
>>>>>>>>>>>>
>>>>>>>>>>>> A bundle is in aries bound to the pid. So it is actually
>>>>>>>>>>>> working as expected, bit of
>>>>>>>>>>>> a hassle since spring-dm allowed it.
>>>>>>>>>>>>
>>>>>>>>>>>> And yes selling DS into “regular" organizations is about as
>>>>>>>>>>>> easy as selling snow in Alaska.
>>>>>>>>>>>>
>>>>>>>>>>>> /je
>>>>>>>>>>>>
>>>>>>>>>>>> On Jul 7, 2016, at 12:00 PM, Brad Johnson <
>>>>>>>>>>>> brad.john...@mediadriver.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> David,
>>>>>>>>>>>>
>>>>>>>>>>>> You live in a very different world than I do. In all the
>>>>>>>>>>>> consulting I do with Fuse/karaf blueprint is used almost
>>>>>>>>>>>> exclusively. I
>>>>>>>>>>>> understand DS and its uses but also its limits and overhead. It's
>>>>>>>>>>>> like
>>>>>>>>>>>> telling me one should only use Camel Java DSL. That may be one's
>>>>>>>>>>>> perspective but that isn't everyone's.
>>>>>>>>>>>>
>>>>>>>>>>>> Brad
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Jul 7, 2016 at 12:53 PM, David Jencks <
>>>>>>>>>>>> david_jen...@yahoo.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> IMNSHO blueprint is only really plausible if you have a large
>>>>>>>>>>>>> amount of Spring based code and you need to convert it to be sort
>>>>>>>>>>>>> of
>>>>>>>>>>>>> osgi-compatible really quickly without understanding osgi or the
>>>>>>>>>>>>> code.
>>>>>>>>>>>>> Otherwise taking the time to understand DS and use it is much more
>>>>>>>>>>>>> satisfactory. DS provides this configuration override ability
>>>>>>>>>>>>> with support
>>>>>>>>>>>>> for multiple pids, although only one of the pids can turn out to
>>>>>>>>>>>>> be a
>>>>>>>>>>>>> factory configuration. There’s no obvious way of correlating
>>>>>>>>>>>>> factory
>>>>>>>>>>>>> configurations, so this restriction makes some sense.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I don’t think there really are any blueprint folks. The cm
>>>>>>>>>>>>> stuff, while obviously required to make the spec remotely
>>>>>>>>>>>>> plausible, hasn’t
>>>>>>>>>>>>> made it into the spec in the many many years it’s been sitting
>>>>>>>>>>>>> around.
>>>>>>>>>>>>>
>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Jul 7, 2016, at 10:41 AM, Brad Johnson <
>>>>>>>>>>>>> brad.john...@mediadriver.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> If I were to sit down with the blueprint folks today to create
>>>>>>>>>>>>> a wish list one thing I'd like to see is for an ability to have a
>>>>>>>>>>>>> configuration hierarchy specified with parent/child relationships
>>>>>>>>>>>>> much like
>>>>>>>>>>>>> one has in Maven. Have a base configuration file and be able to
>>>>>>>>>>>>> have
>>>>>>>>>>>>> another cfg file specify that one as its parent. Override
>>>>>>>>>>>>> properties or add
>>>>>>>>>>>>> them to the child. When the configuration admin fires up it
>>>>>>>>>>>>> would read up
>>>>>>>>>>>>> the chain and construct the properties.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson <
>>>>>>>>>>>>> brad.john...@mediadriver.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ray,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If I understand your question right the answer is the Aries
>>>>>>>>>>>>>> extension is referencing configuration. In karaf/fuse for
>>>>>>>>>>>>>> example the
>>>>>>>>>>>>>> following:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <cm:property-placeholder persistent-id="com.my.foo"
>>>>>>>>>>>>>> update-strategy="reload">
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> will load properties from etc/com.my.foo.cfg
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Installing that file is done either manually or by use of a
>>>>>>>>>>>>>> features file.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Whenever I've attempted to use the PID in more than one
>>>>>>>>>>>>>> bundle it has failed and I don't think it is permitted. That's
>>>>>>>>>>>>>> a problem I
>>>>>>>>>>>>>> think and something that should be fixed through some other
>>>>>>>>>>>>>> configuration
>>>>>>>>>>>>>> management mechanism. Making microservices that might share
>>>>>>>>>>>>>> common
>>>>>>>>>>>>>> properties, for example, becomes problematic in that regard and
>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>> resorted to using my own OSGi services to overcome that problem.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Brad
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <
>>>>>>>>>>>>>> raymond.a...@liferay.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ok, so after a brief review the cm schema is an Aries
>>>>>>>>>>>>>>> extension and it doesn't appear to support the location binding.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> However, it's unclear to me whether this extension is
>>>>>>>>>>>>>>> creating the configuration or merely referencing one from
>>>>>>>>>>>>>>> outside.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Any Aries gurus can answer that?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - Ray
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <
>>>>>>>>>>>>>>> david_jen...@yahoo.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I’m not really familiar with blueprint cm but I’d expect
>>>>>>>>>>>>>>>> that to indicate which pid to use to fetch the config from
>>>>>>>>>>>>>>>> config admin and
>>>>>>>>>>>>>>>> in the ... how to map configuration propertiething blueprint
>>>>>>>>>>>>>>>> substitution
>>>>>>>>>>>>>>>> knows about. Is that really instructions to create a new
>>>>>>>>>>>>>>>> configuration and
>>>>>>>>>>>>>>>> populate it with data (what a management agent does)?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Jul 7, 2016, at 8:19 AM, Raymond Auge <
>>>>>>>>>>>>>>>> raymond.a...@liferay.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> David, I agree with everything you've said, however this
>>>>>>>>>>>>>>>> looks like blueprint being the agent here:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>>>>>>>>>>>> update-strategy="reload">
>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>> </cm:property-placeholder>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - Ray
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <
>>>>>>>>>>>>>>>> david_jen...@yahoo.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No, blueprint cm shouldn’t really know about the
>>>>>>>>>>>>>>>>> multi-location. The management agent that is creating the
>>>>>>>>>>>>>>>>> configuration
>>>>>>>>>>>>>>>>> should be setting the bundle location to the multi-location
>>>>>>>>>>>>>>>>> ”?”.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <
>>>>>>>>>>>>>>>>> pablo.go...@faw.jku.at> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I see and would it possible to configure which method is
>>>>>>>>>>>>>>>>> invoked from Blueprint?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This is how I do it:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>>>>>>>>>>>>> update-strategy="reload">
>>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>> </cm:property-placeholder>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> is there perhaps some blueprint property where I can tune
>>>>>>>>>>>>>>>>> the second argument in the createFactoryConfiguration?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Because it looks like the fact of using config admin
>>>>>>>>>>>>>>>>> through blueprint binds the PID to the first bundle using it
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> best
>>>>>>>>>>>>>>>>> Pablo
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> As long as configurations are not bound to a bundle they
>>>>>>>>>>>>>>>>> can be used by any bundle.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The exception clearly shows that the configuration is
>>>>>>>>>>>>>>>>> bound to a bundle.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Creating an unbound configuration requires passing a "?"
>>>>>>>>>>>>>>>>> as the second arguments to
>>>>>>>>>>>>>>>>> getConfiguration/createFactoryConfiguration
>>>>>>>>>>>>>>>>> methods of CM.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> HTH,
>>>>>>>>>>>>>>>>> - Ray
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <
>>>>>>>>>>>>>>>>> brad.john...@mediadriver.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I don't think that's possible.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <
>>>>>>>>>>>>>>>>>> pablo.go...@faw.jku.at> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hello All,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Is it possible to use same config file from
>>>>>>>>>>>>>>>>>>> multiple bundles while using Config Admin with blueprint
>>>>>>>>>>>>>>>>>>> Blueprint?
>>>>>>>>>>>>>>>>>>> Because, I can't manage to do that, I get the following
>>>>>>>>>>>>>>>>>>> error:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> MESSAGE Cannot use configuration test.mybundle for [
>>>>>>>>>>>>>>>>>>> org.osgi.service.cm.ManagedService, id=214,
>>>>>>>>>>>>>>>>>>> bundle=86/initial@reference:file:../plugin-1/]: No
>>>>>>>>>>>>>>>>>>> visibility to configuration bound to
>>>>>>>>>>>>>>>>>>> initial@reference:file:../plugin-2/
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I saw in this jira a bug opened:
>>>>>>>>>>>>>>>>>>> https://issues.jboss.org/browse/ENTESB-3959
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> However, I fear that this is a problem in the aries
>>>>>>>>>>>>>>>>>>> blueprint implementation as I'm not using KARAF nor FUSE,
>>>>>>>>>>>>>>>>>>> just a plain osgi
>>>>>>>>>>>>>>>>>>> container. Either that or I'm missing some blueprint
>>>>>>>>>>>>>>>>>>> configuration. I'm
>>>>>>>>>>>>>>>>>>> basically using blueprint:cm
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> As a workaround I can make a config file per bundle that
>>>>>>>>>>>>>>>>>>> needs it....
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> As follows the versions and bundles that I'm using
>>>>>>>>>>>>>>>>>>> related to the container (Running on top of Equinox 3.11):
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ID|State |Level|Name
>>>>>>>>>>>>>>>>>>> 5|Active | 2|Apache Aries Whiteboard support
>>>>>>>>>>>>>>>>>>> for JMX DynamicMBean services (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>>>> 6|Active | 2|Apache Aries JNDI Core
>>>>>>>>>>>>>>>>>>> (1.0.2)|1.0.2
>>>>>>>>>>>>>>>>>>> 13|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>>> Topology Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>>>>>>>>>>>>>>>>>> 21|Active | 2|Apache Aries JNDI API
>>>>>>>>>>>>>>>>>>> (1.1.0)|1.1.0
>>>>>>>>>>>>>>>>>>> 25|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>>> Discovery Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>>> 27|Active | 2|Apache Aries Blueprint CM
>>>>>>>>>>>>>>>>>>> (1.0.7)|1.0.7
>>>>>>>>>>>>>>>>>>> 29|Active | 2|Apache Aries JMX Blueprint Core
>>>>>>>>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>>>> 37|Active | 2|Apache Aries JNDI URL Handler
>>>>>>>>>>>>>>>>>>> (1.1.0)|1.1.0
>>>>>>>>>>>>>>>>>>> 42|Active | 2|Apache Aries JMX Core
>>>>>>>>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>>>> 46|Active | 2|Apache Aries Blueprint Core
>>>>>>>>>>>>>>>>>>> (1.5.0)|1.5.0
>>>>>>>>>>>>>>>>>>> 47|Resolved | 4|Apache Aries Blueprint Core
>>>>>>>>>>>>>>>>>>> Compatiblity Fragment Bundle (1.0.0)|1.0.0
>>>>>>>>>>>>>>>>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>>>>>>>>>>>>>>>>>> 56|Active | 2|Aries JPA Container Managed
>>>>>>>>>>>>>>>>>>> Contexts (1.0.4)|1.0.4
>>>>>>>>>>>>>>>>>>> 59|Active | 2|Apache Aries Proxy API
>>>>>>>>>>>>>>>>>>> (1.0.1)|1.0.1
>>>>>>>>>>>>>>>>>>> 67|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>>> Service Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>>> 71|Active | 2|Apache Aries Transaction
>>>>>>>>>>>>>>>>>>> Blueprint (1.1.1)|1.1.1
>>>>>>>>>>>>>>>>>>> 73|Active | 2|Aries JPA Container API
>>>>>>>>>>>>>>>>>>> (1.0.2)|1.0.2
>>>>>>>>>>>>>>>>>>> 77|Active | 2|Apache Aries JNDI Support for
>>>>>>>>>>>>>>>>>>> Legacy Runtimes (1.0.0)|1.0.0
>>>>>>>>>>>>>>>>>>> 88|Active | 2|Apache Aries JMX Blueprint API
>>>>>>>>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>>>> 89|Active | 2|Apache Aries Transaction Manager
>>>>>>>>>>>>>>>>>>> (1.3.0)|1.3.0
>>>>>>>>>>>>>>>>>>> 94|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>>> Discovery Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>>> 97|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>>> provider TCP (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>>> 110|Active | 2|Apache Aries Blueprint
>>>>>>>>>>>>>>>>>>> Annotation API (1.0.1)|1.0.1
>>>>>>>>>>>>>>>>>>> 120|Active | 2|Apache Aries Transaction
>>>>>>>>>>>>>>>>>>> Blueprint (2.1.0)|2.1.0
>>>>>>>>>>>>>>>>>>> 123|Active | 2|Apache Aries JMX API
>>>>>>>>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>>>> 130|Active | 2|Apache Aries Blueprint
>>>>>>>>>>>>>>>>>>> Annotation Impl (1.0.1)|1.0.1
>>>>>>>>>>>>>>>>>>> 132|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>>> Discovery Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>>> 134|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>>> Discovery Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>>> 138|Active | 3|Aries Remote Service Admin Core
>>>>>>>>>>>>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>>> 139|Active | 2|Apache Aries JNDI RMI Handler
>>>>>>>>>>>>>>>>>>> (1.0.0)|1.0.0
>>>>>>>>>>>>>>>>>>> 143|Active | 2|Apache Aries Proxy Service
>>>>>>>>>>>>>>>>>>> (1.0.4)|1.0.4
>>>>>>>>>>>>>>>>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic
>>>>>>>>>>>>>>>>>>> Weaving Bundle (1.0.8)|1.0.8
>>>>>>>>>>>>>>>>>>> 147|Active | 2|Aries JPA Container blueprint
>>>>>>>>>>>>>>>>>>> integration for Aries blueprint (1.0.4)|1.0.4
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 11|Active | 4|Apache Felix File Install
>>>>>>>>>>>>>>>>>>> (3.5.4)|3.5.4
>>>>>>>>>>>>>>>>>>> 19|Active | 4|Apache Felix Gogo Shell
>>>>>>>>>>>>>>>>>>> (0.12.0)|0.12.0
>>>>>>>>>>>>>>>>>>> 57|Active | 4|Apache Felix Gogo Command
>>>>>>>>>>>>>>>>>>> (0.16.0)|0.16.0
>>>>>>>>>>>>>>>>>>> 104|Active | 4|Apache Felix Coordinator Service
>>>>>>>>>>>>>>>>>>> (1.0.2)|1.0.2
>>>>>>>>>>>>>>>>>>> 109|Active | 4|Apache Felix Gogo Runtime
>>>>>>>>>>>>>>>>>>> (0.16.2)|0.16.2
>>>>>>>>>>>>>>>>>>> 114|Active | 4|Apache Felix Web Management
>>>>>>>>>>>>>>>>>>> Console (1.2.8)|1.2.8
>>>>>>>>>>>>>>>>>>> 148|Active | 4|Apache Felix Configuration Admin
>>>>>>>>>>>>>>>>>>> Service (1.8.8)|1.8.8
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 0|Active | 0|OSGi System Bundle
>>>>>>>>>>>>>>>>>>> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> WARNING: Computer viruses can be transmitted via email.
>>>>>>>>>>>>>>>>>>> The recipient should check this email and any attachments
>>>>>>>>>>>>>>>>>>> for the presence
>>>>>>>>>>>>>>>>>>> of viruses. The company accepts no liability for any damage
>>>>>>>>>>>>>>>>>>> caused by any
>>>>>>>>>>>>>>>>>>> virus transmitted by this email. E-mail transmission cannot
>>>>>>>>>>>>>>>>>>> be guaranteed
>>>>>>>>>>>>>>>>>>> to be secure or error-free as information could be
>>>>>>>>>>>>>>>>>>> intercepted, corrupted,
>>>>>>>>>>>>>>>>>>> lost, destroyed, arrive late or incomplete, or contain
>>>>>>>>>>>>>>>>>>> viruses. The sender
>>>>>>>>>>>>>>>>>>> therefore does not accept liability for any errors or
>>>>>>>>>>>>>>>>>>> omissions in the
>>>>>>>>>>>>>>>>>>> contents of this message, which arise as a result of e-mail
>>>>>>>>>>>>>>>>>>> transmission.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Warning: Although the company has taken reasonable
>>>>>>>>>>>>>>>>>>> precautions to ensure no viruses are present in this email,
>>>>>>>>>>>>>>>>>>> the company
>>>>>>>>>>>>>>>>>>> cannot accept responsibility for any loss or damage arising
>>>>>>>>>>>>>>>>>>> from the use of
>>>>>>>>>>>>>>>>>>> this email or attachments.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> *Raymond Augé*
>>>>>>>>>>>>>>>>> <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>>>>>>>>>> (@rotty3000)
>>>>>>>>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance
>>>>>>>>>>>>>>>>> <http://osgi.org/> (@OSGiAlliance)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> *Raymond Augé*
>>>>>>>>>>>>>>>> <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>>>>>>>>> (@rotty3000)
>>>>>>>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance
>>>>>>>>>>>>>>>> <http://osgi.org/> (@OSGiAlliance)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> *Raymond Augé*
>>>>>>>>>>>>>>> <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>>>>>>>> (@rotty3000)
>>>>>>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance
>>>>>>>>>>>>>>> <http://osgi.org/> (@OSGiAlliance)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matt Sicker <boa...@gmail.com>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> ------------------------
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Red Hat, Open Source Integration
>>>>>>
>>>>>> Email: gno...@redhat.com
>>>>>> Web: http://fusesource.com
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Matt Sicker <boa...@gmail.com>
>>>
>>
>>
>
--
Matt Sicker <boa...@gmail.com>
