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
_______________________________________________
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general
