You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Matt Madhavan <ma...@gmail.com> on 2011/05/23 18:47:51 UTC
Spring like Bean definition profiles in/for OSGi/Blueprint - An
interesting question
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
Re: Spring like Bean definition profiles in/for OSGi/Blueprint - An
interesting question
Posted by 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
>>
>
>
>
Re: Spring like Bean definition profiles in/for OSGi/Blueprint - An
interesting question
Posted by 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
>>
>
>
>
Re: Spring like Bean definition profiles in/for OSGi/Blueprint - An interesting question
Posted by David Jencks <da...@yahoo.com>.
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
>
Re: Spring like Bean definition profiles in/for OSGi/Blueprint - An
interesting question
Posted by Matt Madhavan <ma...@gmail.com>.
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
>
Re: Spring like Bean definition profiles in/for OSGi/Blueprint - An
interesting question
Posted by Matt Madhavan <ma...@gmail.com>.
Hi Alasdair,
I got it to working thx! A little timing issue!
Matt
On Wed, May 25, 2011 at 3:13 PM, Alasdair Nottingham <no...@apache.org> wrote:
> Has the host bundle been activated? I assume it is an eager bean?
>
> On 25 May 2011 15:37, Matt Madhavan <ma...@gmail.com> wrote:
> > Hi Alasdair,
> > Thanks for the reply! I created a new fragment bundle for my datasouce. I
> > have a bean inside the fragment which populates the database when its
> init
> > method gets called.
> > The problem is the the bean inside the fragment never gets created! Any
> > ideas? Please note that this is a simple bean and I'm not creating any
> > service out of this.
> > 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 <
> david_jencks@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
> >
> >
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
Re: Spring like Bean definition profiles in/for OSGi/Blueprint - An
interesting question
Posted by Alasdair Nottingham <no...@apache.org>.
Has the host bundle been activated? I assume it is an eager bean?
On 25 May 2011 15:37, Matt Madhavan <ma...@gmail.com> wrote:
> Hi Alasdair,
> Thanks for the reply! I created a new fragment bundle for my datasouce. I
> have a bean inside the fragment which populates the database when its init
> method gets called.
> The problem is the the bean inside the fragment never gets created! Any
> ideas? Please note that this is a simple bean and I'm not creating any
> service out of this.
> 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
>
>
--
Alasdair Nottingham
not@apache.org
Re: Spring like Bean definition profiles in/for OSGi/Blueprint - An
interesting question
Posted by Matt Madhavan <ma...@gmail.com>.
Hi Alasdair,
Thanks for the reply! I created a new fragment bundle for my datasouce. I
have a bean inside the fragment which populates the database when its init
method gets called.
The problem is the the bean inside the fragment never gets created! Any
ideas? Please note that this is a simple bean and I'm not creating any
service out of this.
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
>
Re: Spring like Bean definition profiles in/for OSGi/Blueprint - An
interesting question
Posted by Alasdair Nottingham <no...@apache.org>.
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
Re: Spring like Bean definition profiles in/for OSGi/Blueprint - An
interesting question
Posted by Matt Madhavan <ma...@gmail.com>.
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
>
>
Re: Spring like Bean definition profiles in/for OSGi/Blueprint - An interesting question
Posted by David Jencks <da...@yahoo.com>.
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
Re: Spring like Bean definition profiles in/for OSGi/Blueprint - An
interesting question
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tue, Jun 7, 2011 at 5:42 PM, Peter Kriens <pe...@aqute.biz> wrote:
> I took a quick peek at thee profiles and for me they seem to be the antithesis of what OSGi is about ... :-(
I fail to see how Bean Definition Profiles are more antithesis than
Blueprint in general, and you didn't object (like I did) to that spec
entering OSGi... Perhaps you've gotten wiser, Peter ;-)
IIUIC, this will in fact lower the risk of messing with production
XML, if developer does some imports from files with proper
names/locations to minimize the risks. So, although I am generally
negative to Blueprint and Spring in general, for those that use it,
the suggestion seems to make sense.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/3xugrbk
I work here; http://tinyurl.com/24svnvk
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Spring like Bean definition profiles in/for OSGi/Blueprint - An interesting question
Posted by Peter Kriens <pe...@aqute.biz>.
I took a quick peek at thee profiles and for me they seem to be the antithesis of what OSGi is about ... :-(
Though it might be convenient in your current setup the model centralizes all information in one place. Though this has advantages sometimes it also means that you XML file becomes a hotspot: anything you want to do requires changing the XML file. You also lower the cohesion this way. Do you really want to mix test stuff with production stuff? In my experience you do not want to run the chance that a tester makes a change in this XML file that could screw production. I also think it is bad practice that as deployer in production have to understand what is part of the test env. and what is my production environment. As a tester I always have to go through this centralized file, I cannot create decoupled variations. Worse, this XML file has a tendency to be coupled to almost every instance class in your system. The bean profiles seem to be more a solution required by the accidental complexity of the Spring architecture than a fundamental issue.
In OSGi, your DataSource would be registered as a service and your test and production code would just depend on a DataSource. Where that DataSource should come from should not be your problem as a developer. This allows the deployer (which might be you in another role, but it is crucial to separate those roles) to configure the system with different bundles depending on how he wants to use the system. In test, you would run it with other bundles (or configuration) then in production. This makes bundles much less coupled.
The problem is that many people try to use OSGi as an application server running independent programs in the same framework. However, it has always been the intention that the services in the service registry were intended for you, the bundles installed in the same framework must have high cohesion.
So I think the OSGi services provides a better solution to the problem of having different configurations than the bean profiles. However, that does not have to stop the OSGi to develop something similar as its native model is often not well understood by enterprise developers.
Kind regards,
Peter Kriens
On 23 mei 2011, at 18:47, 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
> _______________________________________________
> general mailing list
> general@lists.ops4j.org
> http://lists.ops4j.org/mailman/listinfo/general
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org