Hi Matt, not sure if Alasdair will be online soon...
You'd put your main logic and blueprint beans into one bundle A that depends on a datasource bean, which it does not supply. Then you have two fragment bundles F1 and F2 each of which defines a datasource bean suitable for A, one fragment for each profile. Both fragments specify A as Fragment-Host. You can then deploy A + F1 or A + F2 to get a complete "A" functionality. This has the advantage over the approach I suggested that it completely conceals the datasource used in A from anything outside A. hope this is clearer... david jencks On May 26, 2011, at 1:07 PM, Matt Madhavan wrote: > Hi Alasdair, > Can you please elaborate the following line you wrote - I'm not quite clear > on this one! > > So going by the example on the blog you would have a > core blueprint, one that uses a DataSource from JNDI and one that > creates an embedded one. You can add these into 1 bundle and 2 > fragments and deploy whichever mix you need. > > Thanks > Matt > > On Mon, May 23, 2011 at 5:14 PM, Alasdair Nottingham <[email protected]> wrote: > As David says you can use different bundles and the service registry > to get the behaviour of bean definition profiles if you want. > > An additional approach that works in blueprint and is a result of > being integrated into OSGi is to have a core bundle which defines the > core behaviour and have a fragment bundle for each profile. The > profile fragments each have a blueprint that defines the specifics for > that environment. So going by the example on the blog you would have a > core blueprint, one that uses a DataSource from JNDI and one that > creates an embedded one. You can add these into 1 bundle and 2 > fragments and deploy whichever mix you need. > > Alasdair > > On 23 May 2011 19:28, Matt Madhavan <[email protected]> wrote: > > David, > > I used all the three main lists because I wanted to reach out to a bigger > > audience. > > I'm kind of leaning towards what you have suggested below. But I was > > wondering how others are tackling this issue. I'm sure I'm not the only one > > with this issue! > > Thanks > > Matt > > > > On Mon, May 23, 2011 at 12:54 PM, David Jencks <[email protected]> > > wrote: > >> > >> Kind of a wide range of mailing lists for your question.... > >> > >> why wouldn't you have different bundles for different profiles, > >> registering services with the same interfaces and properties? You don't > >> even need to use blueprint for all your profile bundles. It seems to me > >> that bean definition profiles are kind of a workaround for the lack of > >> flexibility in non-osgi environments. > >> > >> thanks > >> david jencks > >> > >> On May 23, 2011, at 9:47 AM, Matt Madhavan wrote: > >> > >> > Hello All, > >> > This is an interesting question for you all! > >> > > >> > For all these years Spring users have been building custom built > >> > solution > >> > for Bean Definition Profiles which is now part of the Spring 3.1 > >> > (currently > >> > M1). > >> > > >> > The following blog talks about the Bean Definition Profile > >> > > >> > http://blog.springsource.com/2011/02/11/spring-framework-3-1-m1-released/ > >> > > >> > Is there an equivalent Framework/development work available/going on for > >> > OSGi/Blueprint. I'm just curious. > >> > > >> > Regardless, I feel this may lead to an interesting discussion. This > >> > technology may prove crucial as OSGi is used in more Enterprise > >> > development. > >> > > >> > Thanks > >> > Matt > >> > > > > > > > > -- > Alasdair Nottingham > [email protected] >
