Re: Spring like Bean definition profiles in/for OSGi/Blueprint - An interesting question

[Matt Madhavan <ma...@gmail.com>]

Hi David,
Sorry for the late reply! I had started an internal debate here at my client
team regarding this.

Question for you though. Your solution below works great, But it also means
that I have to build one EBA for each env/profile. For instance if I have
two profiles (F1 and F2) I have to build one say F1.eba (containing bundle
A+Fragment F1) and F2.eba (containing A+Fragment F2) right?

This is the first  OSGI POC my client(rather a large one). My client is used
to having  only one EAR file for all the env's. At startup they look up an
env and load the appropriate properties from DB!

Or should I have A, F! and F2 all in the same eba and look up the necessary
service based on an OSGi filter? This could be a little dangerous since for
dev I have a fragment load data to an in memory derby DB and in prod I may
accidently load data into a PROD DB?

Just thinking out aloud! Any ideas?

Thanks in advance!
 Matt

On Thu, May 26, 2011 at 3:21 PM, David Jencks <da...@yahoo.com>wrote:

> 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 <no...@apache.org>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 <ma...@gmail.com> 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 <da...@yahoo.com>
>> > 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
>> not@apache.org
>>
>
>
>