Hi Guillaume,
I am curious about this blueprint implementation you mentioned. Is it
opensourced? If yes is there any link I can check it out? If no why not? :)
Thanks!
On Sun, Jun 21, 2009 at 5:28 AM, Guillaume Nodet gno...@gmail.com wrote:
Great presentations ! Thx for sharing those links.
Hi Todor,
very informative post! thanks.
http://rinswind.blogspot.com/2009/05/service-dynamics-lazy-mans-way.html
It is a work in progress so I'd appreciate any input :)
--
Dmitry Skavish
The blueprint implementation is available at
http://svn.apache.org/repos/asf/geronimo/sandbox/blueprint
Just tell me if you have any problems building it (running mvn should work).
The target bundle will be available in
blueprint-bundle/target/blueprint-bundle-1.0.0-SNAPSHOT.jar
On Mon, Jun
This sentence I do not understand: Service dynamics is one of the key
points of OSGi.
The key usage of dynamics is hot code update. Direct service references plus
concurrent bundle updates make handling service dynamics quite disruptive to the
normal application code.You have to sprinkle
Todor Boev wrote:
Here's a descent comparison between Spring DM, OSGi DS and iPojo.
http://www.slideshare.net/heiko.seeberger/jax-09-osgi-service-components-models
I actually meant to post this here detailed three way comparison:
Hi,
Todor Boev schrieb:
This sentence I do not understand: Service dynamics is one of the key
points of OSGi.
The key usage of dynamics is hot code update. Direct service references plus
concurrent bundle updates make handling service dynamics quite disruptive to
the
normal application
Hi,
Todor Boev schrieb:
I would
not go with OSGi DS since it does not really do much to shield you from
the service dynamics.
This sentence I do not understand: Service dynamics is one of the key
points of OSGi.
But it is correct, the current specification of DS requires a lot of
OSGi API to
On Thu, Jun 18, 2009 at 4:45 AM, Dmitry Skavishskav...@gmail.com wrote:
On Mon, Jun 15, 2009 at 10:13 AM, Todor Boev t.b...@prosyst.bg wrote:
Dmitry Skavish wrote:
Hello all,
I am trying to understand the differences between those technologies, but
I
could not find any article which
Unfortunately we can't do bytecode manipulations, so iPOJO is out of the
question. And I am not really happy with all this iPOJO magic with
private
fields.
iPOJO does the manipulation at packaging time (think of it as another
compiler). There is an online manipulator as well but for the
FWIW, Spring-DM is being standardized as Blueprint services.
You can find an implementation of the spec (soon to be published) at
http://svn.apache.org/repos/asf/geronimo/sandbox/blueprint/
Blueprint is much more powerfull wrt dependency injection than DS / iPojo.
The runtime is 300k, so it's
On 6/18/09 10:35 AM, Guillaume Nodet wrote:
FWIW, Spring-DM is being standardized as Blueprint services.
You can find an implementation of the spec (soon to be published) at
http://svn.apache.org/repos/asf/geronimo/sandbox/blueprint/
Blueprint is much more powerfull wrt dependency injection
Yeah, dependency injection, the fact that you can inject much more
things than just simple values (collections, maps, arrays.
You can also define custom converters to handle legacy code.
On Thu, Jun 18, 2009 at 16:50, Richard S. Hallhe...@ungoverned.org wrote:
On 6/18/09 10:35 AM, Guillaume
On 6/18/09 10:56 AM, Guillaume Nodet wrote:
Yeah, dependency injection, the fact that you can inject much more
things than just simple values (collections, maps, arrays.
This doesn't make sense to me. Dependency injection is covered by iPOJO.
Property injection is no DI, it is
I guess what I mean is that iPojo imposes some contraints on the pojo
you build and wire together.
Whereas the goal of blueprint is to be able to wire any legacy code
without introducing any dependency on the OSGi API.
IPojo hides some of the OSGi internals but if you take a look at
On 18.06.2009, at 17:18, Guillaume Nodet wrote:
I guess what I mean is that iPojo imposes some contraints on the pojo
you build and wire together.
Whereas the goal of blueprint is to be able to wire any legacy code
without introducing any dependency on the OSGi API.
IPojo hides some of the
On 6/18/09 11:18 AM, Guillaume Nodet wrote:
I guess what I mean is that iPojo imposes some contraints on the pojo
you build and wire together.
Whereas the goal of blueprint is to be able to wire any legacy code
without introducing any dependency on the OSGi API.
IPojo hides some of the OSGi
On Mon, Jun 15, 2009 at 10:13 AM, Todor Boev t.b...@prosyst.bg wrote:
Dmitry Skavish wrote:
Hello all,
I am trying to understand the differences between those technologies, but
I
could not find any article which compares all them side by side.
Can somebody summarize pros and cons or point
Hello all,
I am trying to understand the differences between those technologies, but I
could not find any article which compares all them side by side.
Can somebody summarize pros and cons or point me to page where this is
already done?
We are using Guice, so I guess the logical way is to use
Dmitry Skavish wrote:
Hello all,
I am trying to understand the differences between those technologies, but I
could not find any article which compares all them side by side.
Can somebody summarize pros and cons or point me to page where this is
already done?
We are using Guice, so I guess the
19 matches
Mail list logo
