You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@aries.apache.org by "Lichota, Lukasz" <Lu...@sabre.com> on 2010/05/17 14:36:19 UTC
questions to Overview.ppt
I have a few questions to this presentation:
https://svn.apache.org/repos/asf/incubator/aries/slides/Apache%20Aries%2
0-%20Overview.ppt
1. Slide #6 - Simplifies unit test outside either Java EE or OSGi r/t.
How can blueprint context can be unit tested outside OSGi? Any example?
2. Slide #8 For integration of blueprint with jta/jpa aries specific
namespaces are used.
xmlns:jta="http://aries.apache.org/xmlns/transactions/v1.0.0"
xmlns:jpa="http://aries.apache.org/xmlns/jpa/v1.0.0"
Are there plans to include it in specification? Why doesn't the spec
address integration with blueprint? (which is also covered by the spec).
Best regards,
Lukasz
Re: questions to Overview.ppt
Posted by Jeremy Hughes <hu...@apache.org>.
On 18 May 2010 13:30, Lichota, Lukasz <Lu...@sabre.com> wrote:
>> What you are seeing is an example of that and welcome your feedback - and from what you're saying it sounds like you would like that standardised.
>
> Yes, I haven't played much with Aries but that's my impression it's nice to standardize it. If something called "extension" is used in let's say 60% of use cases than for me it's not an extension any more. It's just wording but what I mean here is that a good spec should cover 70% of use cases fully. Would you agree?
The Blueprint spec specifically describes 'Extensions' in section
121.3.3. So it provides a standard way of writing extensions in
non-standard namespaces :-) It is up to the OSGi Alliance and members
as to whether the JPA and JTA extensions we have in Aries will be
pulled into the Blueprint specification, stand in their own
specification or get added to the JPA or JTA spec accordingly.
So I think extensions *can* remain extensions if they are used 60 or
70% of the time ... it's just another way of saying something is
modular.
>
> Best regards,
> Lukasz
>
> -----Original Message-----
> From: jpjhughes@gmail.com [mailto:jpjhughes@gmail.com] On Behalf Of Jeremy Hughes
> Sent: Tuesday, May 18, 2010 12:50 PM
> To: aries-user@incubator.apache.org
> Subject: Re: questions to Overview.ppt
>
> On 18 May 2010 08:22, Lichota, Lukasz <Lu...@sabre.com> wrote:
>> Hi Valentin,
>>
>>
>>
>> Thanks for answers, for #2 it's a pity that it was dropped. I think if
>> community is to really benefit from having a spec then all things typically
>> used should be there. And since this "extension" happens to appear in basic
>> example in "overview" presentation it simply means it's something commonly
>> used. The conclusion is that even 'hello world' example would be bound to
>> implementation ;-)
>
> For now that is correct - the sample is bound to a non-standard
> namespace. In Aries we didn't want to limit ourselves to implementing
> finished specifications:
>
> "The project will develop extensions that go beyond the OSGi EEG
> specifications to provide a more complete integration of OSGi
> modularity with Java enterprise technologies ..." [1]
>
> We are actively working on new, not-yet-standardised technology which
> could potentially be standardised. What you are seeing is an example
> of that and welcome your feedback - and from what you're saying it
> sounds like you would like that standardised.
>
> [1] http://wiki.apache.org/incubator/AriesProposal
>
>>
>> The same touches cm and ext namespaces for blueprint.
>>
>>
>>
>> Best regards,
>>
>> Lukasz
>>
>> ________________________________
>>
>> From: Valentin Mahrwald [mailto:vmahrwald@googlemail.com]
>> Sent: Monday, May 17, 2010 9:51 PM
>> To: aries-user@incubator.apache.org
>> Subject: Re: questions to Overview.ppt
>>
>>
>>
>> Hi Lukasz,
>>
>>
>>
>> comments below :)
>>
>>
>>
>> Valentin
>>
>>
>>
>> On 17 May 2010, at 13:36, Lichota, Lukasz wrote:
>>
>> I have a few questions to this
>> presentation: https://svn.apache.org/repos/asf/incubator/aries/slides/Apache%20Aries%20-%20Overview.ppt
>>
>>
>>
>> 1. Slide #6 - Simplifies unit test outside either Java EE or OSGi r/t.
>>
>> How can blueprint context can be unit tested outside OSGi? Any example?
>>
>>
>>
>> Might have misunderstood your question, so apologies if I am trying to
>> answer a different question.
>>
>>
>>
>> I think here the point is that dependency injection as an architecture, if
>> correctly employed, should make code more testable by fostering very loose,
>> interface driven coupling.
>>
>>
>>
>> In OSGi particular terms one benefit for example would be testing components
>> that interact with the OSGi service registry. Using only the OSGi APIs code
>> like the following (abridged, not bad practice!) would be non-trivial and
>> rather annoying to unit test.
>>
>>
>>
>> class MyActivator {
>>
>> ...
>>
>>
>>
>> public void start(BundleContext ctx) {
>>
>> ServiceReference ref
>> = ctx.getServiceReference(GreetingService.class.getName());
>>
>> GreetingService service = (GreetingService)
>> ctx.getService(ref);
>>
>> service.greet();
>>
>> }
>>
>> }
>>
>>
>>
>> One would have to mock up BundleContext, the getServiceReference and
>> getService method calls.
>>
>>
>>
>> Whereas the equivalent(ish) code with blueprint should be significantly
>> easier to unit test since all the code for actually getting hold of an OSGi
>> service is handled by the container. (Similar benefits would be derived from
>> using declarative services) In general since the integration is metadata
>> driven and not encoded in code, the unit testing code does not have to
>> handle it at all.
>>
>>
>>
>> class Greeter {
>>
>> private GreetingService service;
>>
>> public void setGreeter(GreetingService service) { this.service =
>> service; }
>>
>>
>>
>> public void start() {
>>
>> service.greet();
>>
>> }
>>
>> }
>>
>>
>>
>> <blueprint>
>>
>> <bean class="MyBean" init-method="start">
>>
>> <property name="greeter">
>>
>> <reference interface="GreetingService"
>> />
>>
>> </property>
>>
>> </bean>
>>
>> </blueprint>
>>
>>
>>
>> Of course there are still pain points of unit testing code that is injected
>> with Bundle, BundleContext or BlueprintContainer objects. But even then
>> blueprint offers benefits in that the BundleContext does not have to be
>> carefully passed from the Activator through layers of objects to wherever it
>> is needed.
>>
>>
>>
>>
>>
>> 2. Slide #8 For integration of blueprint with jta/jpa aries specific
>> namespaces are used.
>>
>> xmlns:jta="http://aries.apache.org/xmlns/transactions/v1.0.0"
>>
>> xmlns:jpa="http://aries.apache.org/xmlns/jpa/v1.0.0"
>>
>>
>>
>> Are there plans to include it in specification? Why doesn't the spec address
>> integration with blueprint? (which is also covered by the spec).
>>
>>
>>
>> As far as I understand blueprint extension namespace were originally part of
>> the blueprint spec but were dropped fairly late in the day due to technical
>> issues.
>>
>> I would expect that some of these extensions might be tackled in a future
>> revision of the EEG spec.
>>
>>
>>
>> Best regards,
>>
>> Lukasz
>>
>>
>>
>>
>
RE: questions to Overview.ppt
Posted by "Lichota, Lukasz" <Lu...@sabre.com>.
> What you are seeing is an example of that and welcome your feedback - and from what you're saying it sounds like you would like that standardised.
Yes, I haven't played much with Aries but that's my impression it's nice to standardize it. If something called "extension" is used in let's say 60% of use cases than for me it's not an extension any more. It's just wording but what I mean here is that a good spec should cover 70% of use cases fully. Would you agree?
Best regards,
Lukasz
-----Original Message-----
From: jpjhughes@gmail.com [mailto:jpjhughes@gmail.com] On Behalf Of Jeremy Hughes
Sent: Tuesday, May 18, 2010 12:50 PM
To: aries-user@incubator.apache.org
Subject: Re: questions to Overview.ppt
On 18 May 2010 08:22, Lichota, Lukasz <Lu...@sabre.com> wrote:
> Hi Valentin,
>
>
>
> Thanks for answers, for #2 it's a pity that it was dropped. I think if
> community is to really benefit from having a spec then all things typically
> used should be there. And since this "extension" happens to appear in basic
> example in "overview" presentation it simply means it's something commonly
> used. The conclusion is that even 'hello world' example would be bound to
> implementation ;-)
For now that is correct - the sample is bound to a non-standard
namespace. In Aries we didn't want to limit ourselves to implementing
finished specifications:
"The project will develop extensions that go beyond the OSGi EEG
specifications to provide a more complete integration of OSGi
modularity with Java enterprise technologies ..." [1]
We are actively working on new, not-yet-standardised technology which
could potentially be standardised. What you are seeing is an example
of that and welcome your feedback - and from what you're saying it
sounds like you would like that standardised.
[1] http://wiki.apache.org/incubator/AriesProposal
>
> The same touches cm and ext namespaces for blueprint.
>
>
>
> Best regards,
>
> Lukasz
>
> ________________________________
>
> From: Valentin Mahrwald [mailto:vmahrwald@googlemail.com]
> Sent: Monday, May 17, 2010 9:51 PM
> To: aries-user@incubator.apache.org
> Subject: Re: questions to Overview.ppt
>
>
>
> Hi Lukasz,
>
>
>
> comments below :)
>
>
>
> Valentin
>
>
>
> On 17 May 2010, at 13:36, Lichota, Lukasz wrote:
>
> I have a few questions to this
> presentation: https://svn.apache.org/repos/asf/incubator/aries/slides/Apache%20Aries%20-%20Overview.ppt
>
>
>
> 1. Slide #6 - Simplifies unit test outside either Java EE or OSGi r/t.
>
> How can blueprint context can be unit tested outside OSGi? Any example?
>
>
>
> Might have misunderstood your question, so apologies if I am trying to
> answer a different question.
>
>
>
> I think here the point is that dependency injection as an architecture, if
> correctly employed, should make code more testable by fostering very loose,
> interface driven coupling.
>
>
>
> In OSGi particular terms one benefit for example would be testing components
> that interact with the OSGi service registry. Using only the OSGi APIs code
> like the following (abridged, not bad practice!) would be non-trivial and
> rather annoying to unit test.
>
>
>
> class MyActivator {
>
> ...
>
>
>
> public void start(BundleContext ctx) {
>
> ServiceReference ref
> = ctx.getServiceReference(GreetingService.class.getName());
>
> GreetingService service = (GreetingService)
> ctx.getService(ref);
>
> service.greet();
>
> }
>
> }
>
>
>
> One would have to mock up BundleContext, the getServiceReference and
> getService method calls.
>
>
>
> Whereas the equivalent(ish) code with blueprint should be significantly
> easier to unit test since all the code for actually getting hold of an OSGi
> service is handled by the container. (Similar benefits would be derived from
> using declarative services) In general since the integration is metadata
> driven and not encoded in code, the unit testing code does not have to
> handle it at all.
>
>
>
> class Greeter {
>
> private GreetingService service;
>
> public void setGreeter(GreetingService service) { this.service =
> service; }
>
>
>
> public void start() {
>
> service.greet();
>
> }
>
> }
>
>
>
> <blueprint>
>
> <bean class="MyBean" init-method="start">
>
> <property name="greeter">
>
> <reference interface="GreetingService"
> />
>
> </property>
>
> </bean>
>
> </blueprint>
>
>
>
> Of course there are still pain points of unit testing code that is injected
> with Bundle, BundleContext or BlueprintContainer objects. But even then
> blueprint offers benefits in that the BundleContext does not have to be
> carefully passed from the Activator through layers of objects to wherever it
> is needed.
>
>
>
>
>
> 2. Slide #8 For integration of blueprint with jta/jpa aries specific
> namespaces are used.
>
> xmlns:jta="http://aries.apache.org/xmlns/transactions/v1.0.0"
>
> xmlns:jpa="http://aries.apache.org/xmlns/jpa/v1.0.0"
>
>
>
> Are there plans to include it in specification? Why doesn't the spec address
> integration with blueprint? (which is also covered by the spec).
>
>
>
> As far as I understand blueprint extension namespace were originally part of
> the blueprint spec but were dropped fairly late in the day due to technical
> issues.
>
> I would expect that some of these extensions might be tackled in a future
> revision of the EEG spec.
>
>
>
> Best regards,
>
> Lukasz
>
>
>
>
Re: questions to Overview.ppt
Posted by Jeremy Hughes <hu...@apache.org>.
On 18 May 2010 08:22, Lichota, Lukasz <Lu...@sabre.com> wrote:
> Hi Valentin,
>
>
>
> Thanks for answers, for #2 it’s a pity that it was dropped. I think if
> community is to really benefit from having a spec then all things typically
> used should be there. And since this “extension” happens to appear in basic
> example in “overview” presentation it simply means it’s something commonly
> used. The conclusion is that even ‘hello world’ example would be bound to
> implementation ;-)
For now that is correct - the sample is bound to a non-standard
namespace. In Aries we didn't want to limit ourselves to implementing
finished specifications:
"The project will develop extensions that go beyond the OSGi EEG
specifications to provide a more complete integration of OSGi
modularity with Java enterprise technologies ..." [1]
We are actively working on new, not-yet-standardised technology which
could potentially be standardised. What you are seeing is an example
of that and welcome your feedback - and from what you're saying it
sounds like you would like that standardised.
[1] http://wiki.apache.org/incubator/AriesProposal
>
> The same touches cm and ext namespaces for blueprint.
>
>
>
> Best regards,
>
> Lukasz
>
> ________________________________
>
> From: Valentin Mahrwald [mailto:vmahrwald@googlemail.com]
> Sent: Monday, May 17, 2010 9:51 PM
> To: aries-user@incubator.apache.org
> Subject: Re: questions to Overview.ppt
>
>
>
> Hi Lukasz,
>
>
>
> comments below :)
>
>
>
> Valentin
>
>
>
> On 17 May 2010, at 13:36, Lichota, Lukasz wrote:
>
> I have a few questions to this
> presentation: https://svn.apache.org/repos/asf/incubator/aries/slides/Apache%20Aries%20-%20Overview.ppt
>
>
>
> 1. Slide #6 - Simplifies unit test outside either Java EE or OSGi r/t.
>
> How can blueprint context can be unit tested outside OSGi? Any example?
>
>
>
> Might have misunderstood your question, so apologies if I am trying to
> answer a different question.
>
>
>
> I think here the point is that dependency injection as an architecture, if
> correctly employed, should make code more testable by fostering very loose,
> interface driven coupling.
>
>
>
> In OSGi particular terms one benefit for example would be testing components
> that interact with the OSGi service registry. Using only the OSGi APIs code
> like the following (abridged, not bad practice!) would be non-trivial and
> rather annoying to unit test.
>
>
>
> class MyActivator {
>
> ...
>
>
>
> public void start(BundleContext ctx) {
>
> ServiceReference ref
> = ctx.getServiceReference(GreetingService.class.getName());
>
> GreetingService service = (GreetingService)
> ctx.getService(ref);
>
> service.greet();
>
> }
>
> }
>
>
>
> One would have to mock up BundleContext, the getServiceReference and
> getService method calls.
>
>
>
> Whereas the equivalent(ish) code with blueprint should be significantly
> easier to unit test since all the code for actually getting hold of an OSGi
> service is handled by the container. (Similar benefits would be derived from
> using declarative services) In general since the integration is metadata
> driven and not encoded in code, the unit testing code does not have to
> handle it at all.
>
>
>
> class Greeter {
>
> private GreetingService service;
>
> public void setGreeter(GreetingService service) { this.service =
> service; }
>
>
>
> public void start() {
>
> service.greet();
>
> }
>
> }
>
>
>
> <blueprint>
>
> <bean class="MyBean" init-method="start">
>
> <property name="greeter">
>
> <reference interface="GreetingService"
> />
>
> </property>
>
> </bean>
>
> </blueprint>
>
>
>
> Of course there are still pain points of unit testing code that is injected
> with Bundle, BundleContext or BlueprintContainer objects. But even then
> blueprint offers benefits in that the BundleContext does not have to be
> carefully passed from the Activator through layers of objects to wherever it
> is needed.
>
>
>
>
>
> 2. Slide #8 For integration of blueprint with jta/jpa aries specific
> namespaces are used.
>
> xmlns:jta="http://aries.apache.org/xmlns/transactions/v1.0.0"
>
> xmlns:jpa="http://aries.apache.org/xmlns/jpa/v1.0.0"
>
>
>
> Are there plans to include it in specification? Why doesn’t the spec address
> integration with blueprint? (which is also covered by the spec).
>
>
>
> As far as I understand blueprint extension namespace were originally part of
> the blueprint spec but were dropped fairly late in the day due to technical
> issues.
>
> I would expect that some of these extensions might be tackled in a future
> revision of the EEG spec.
>
>
>
> Best regards,
>
> Lukasz
>
>
>
>
RE: questions to Overview.ppt
Posted by "Lichota, Lukasz" <Lu...@sabre.com>.
Hi Valentin,
Thanks for answers, for #2 it's a pity that it was dropped. I think if
community is to really benefit from having a spec then all things
typically used should be there. And since this "extension" happens to
appear in basic example in "overview" presentation it simply means it's
something commonly used. The conclusion is that even 'hello world'
example would be bound to implementation ;-)
The same touches cm and ext namespaces for blueprint.
Best regards,
Lukasz
________________________________
From: Valentin Mahrwald [mailto:vmahrwald@googlemail.com]
Sent: Monday, May 17, 2010 9:51 PM
To: aries-user@incubator.apache.org
Subject: Re: questions to Overview.ppt
Hi Lukasz,
comments below :)
Valentin
On 17 May 2010, at 13:36, Lichota, Lukasz wrote:
I have a few questions to this presentation:
https://svn.apache.org/repos/asf/incubator/aries/slides/Apache%20Aries%2
0-%20Overview.ppt
1. Slide #6 - Simplifies unit test outside either Java EE or OSGi r/t.
How can blueprint context can be unit tested outside OSGi? Any example?
Might have misunderstood your question, so apologies if I am trying to
answer a different question.
I think here the point is that dependency injection as an architecture,
if correctly employed, should make code more testable by fostering very
loose, interface driven coupling.
In OSGi particular terms one benefit for example would be testing
components that interact with the OSGi service registry. Using only the
OSGi APIs code like the following (abridged, not bad practice!) would be
non-trivial and rather annoying to unit test.
class MyActivator {
...
public void start(BundleContext ctx) {
ServiceReference ref =
ctx.getServiceReference(GreetingService.class.getName());
GreetingService service = (GreetingService)
ctx.getService(ref);
service.greet();
}
}
One would have to mock up BundleContext, the getServiceReference and
getService method calls.
Whereas the equivalent(ish) code with blueprint should be significantly
easier to unit test since all the code for actually getting hold of an
OSGi service is handled by the container. (Similar benefits would be
derived from using declarative services) In general since the
integration is metadata driven and not encoded in code, the unit testing
code does not have to handle it at all.
class Greeter {
private GreetingService service;
public void setGreeter(GreetingService service) {
this.service = service; }
public void start() {
service.greet();
}
}
<blueprint>
<bean class="MyBean" init-method="start">
<property name="greeter">
<reference
interface="GreetingService" />
</property>
</bean>
</blueprint>
Of course there are still pain points of unit testing code that is
injected with Bundle, BundleContext or BlueprintContainer objects. But
even then blueprint offers benefits in that the BundleContext does not
have to be carefully passed from the Activator through layers of objects
to wherever it is needed.
2. Slide #8 For integration of blueprint with jta/jpa aries specific
namespaces are used.
xmlns:jta="http://aries.apache.org/xmlns/transactions/v1.0.0"
xmlns:jpa="http://aries.apache.org/xmlns/jpa/v1.0.0"
Are there plans to include it in specification? Why doesn't the
spec address integration with blueprint? (which is also covered by the
spec).
As far as I understand blueprint extension namespace were originally
part of the blueprint spec but were dropped fairly late in the day due
to technical issues.
I would expect that some of these extensions might be tackled in a
future revision of the EEG spec.
Best regards,
Lukasz
Re: questions to Overview.ppt
Posted by Bartosz Kowalewski <ko...@gmail.com>.
Hi Valentin,
I got an impression that Lukasz was thinking of a way to unit test the
whole Blueprint bundle outside of an OSGi container. By saying _the
whole bundle_ I mean classes + the blueprint definitions. I don't think
that it is possible in Apache Aries. However, when I saw this
presentation, this was my first impression: "Aries provides some kind of
tooling for testing Blueprint bundles outside of an OSGi container.
That's cool! No more 1 minute long Pax Exam tests just for checking if I
made a typo in simple Blueprint definitions :)."
When using Spring DM extender it was a best practice to split the
context into two files: a non-OSGi dependent one and an OSGi based one.
It was possible to test the former one outside of an OSGi container.
This was really helpful - some fundamental mistakes were caught early
and simple tests were only run on pure Spring bean without OSGi
(services, references, cm-properties, etc.). This caused running the
whole test suite to take much less time. I don't think that it possible
with Blueprint and if it was, probably a seperate test jar containing a
dedicated tooling would need to be released together with each Aries
version.
Thanks,
Bartek
Valentin Mahrwald wrote the following on 5/17/2010 9:51 PM:
> Hi Lukasz,
>
> comments below :)
>
> Valentin
>
> On 17 May 2010, at 13:36, Lichota, Lukasz wrote:
>
>> I have a few questions to this
>> presentation: https://svn.apache.org/repos/asf/incubator/aries/slides/Apache%20Aries%20-%20Overview.ppt
>>
>> 1. Slide #6 - Simplifies unit test outside either Java EE or OSGi r/t.
>> How can blueprint context can be unit tested outside OSGi? Any example?
>
> Might have misunderstood your question, so apologies if I am trying to
> answer a different question.
>
> I think here the point is that dependency injection as an
> architecture, if correctly employed, should make code more testable by
> fostering very loose, interface driven coupling.
>
> In OSGi particular terms one benefit for example would be testing
> components that interact with the OSGi service registry. Using only
> the OSGi APIs code like the following (abridged, not bad practice!)
> would be non-trivial and rather annoying to unit test.
>
> class MyActivator {
> ...
>
> public void start(BundleContext ctx) {
> ServiceReference ref
> = ctx.getServiceReference(GreetingService.class.getName());
> GreetingService service = (GreetingService) ctx.getService(ref);
> service.greet();
> }
> }
>
> One would have to mock up BundleContext, the getServiceReference and
> getService method calls.
>
> Whereas the equivalent(ish) code with blueprint should be
> significantly easier to unit test since all the code for actually
> getting hold of an OSGi service is handled by the container. (Similar
> benefits would be derived from using declarative services) In general
> since the integration is metadata driven and not encoded in code, the
> unit testing code does not have to handle it at all.
>
> class Greeter {
> private GreetingService service;
> public void setGreeter(GreetingService service) { this.service =
> service; }
>
> public void start() {
> service.greet();
> }
> }
>
> <blueprint>
> <bean class="MyBean" init-method="start">
> <property name="greeter">
> <reference interface="GreetingService" />
> </property>
> </bean>
> </blueprint>
>
> Of course there are still pain points of unit testing code that is
> injected with Bundle, BundleContext or BlueprintContainer objects. But
> even then blueprint offers benefits in that the BundleContext does not
> have to be carefully passed from the Activator through layers of
> objects to wherever it is needed.
>
>
>>
>> 2. Slide #8 For integration of blueprint with jta/jpa aries specific
>> namespaces are used.
>> xmlns:jta="/http://aries.apache.org/xmlns/transactions/v1.0.0/"
>> xmlns:jpa=/"http://aries.apache.org/xmlns/jpa/v1.0.0"/
>>
>> Are there plans to include it in specification? Why doesn’t the spec
>> address integration with blueprint? (which is also covered by the spec).
>
> As far as I understand blueprint extension namespace were originally
> part of the blueprint spec but were dropped fairly late in the day due
> to technical issues.
> I would expect that some of these extensions might be tackled in a
> future revision of the EEG spec.
>
>>
>> Best regards,
>> Lukasz
>>
>
Re: questions to Overview.ppt
Posted by Valentin Mahrwald <vm...@googlemail.com>.
Hi Lukasz,
comments below :)
Valentin
On 17 May 2010, at 13:36, Lichota, Lukasz wrote:
> I have a few questions to this presentation: https://svn.apache.org/repos/asf/incubator/aries/slides/Apache%20Aries%20-%20Overview.ppt
>
> 1. Slide #6 - Simplifies unit test outside either Java EE or OSGi r/t.
> How can blueprint context can be unit tested outside OSGi? Any example?
Might have misunderstood your question, so apologies if I am trying to answer a different question.
I think here the point is that dependency injection as an architecture, if correctly employed, should make code more testable by fostering very loose, interface driven coupling.
In OSGi particular terms one benefit for example would be testing components that interact with the OSGi service registry. Using only the OSGi APIs code like the following (abridged, not bad practice!) would be non-trivial and rather annoying to unit test.
class MyActivator {
...
public void start(BundleContext ctx) {
ServiceReference ref = ctx.getServiceReference(GreetingService.class.getName());
GreetingService service = (GreetingService) ctx.getService(ref);
service.greet();
}
}
One would have to mock up BundleContext, the getServiceReference and getService method calls.
Whereas the equivalent(ish) code with blueprint should be significantly easier to unit test since all the code for actually getting hold of an OSGi service is handled by the container. (Similar benefits would be derived from using declarative services) In general since the integration is metadata driven and not encoded in code, the unit testing code does not have to handle it at all.
class Greeter {
private GreetingService service;
public void setGreeter(GreetingService service) { this.service = service; }
public void start() {
service.greet();
}
}
<blueprint>
<bean class="MyBean" init-method="start">
<property name="greeter">
<reference interface="GreetingService" />
</property>
</bean>
</blueprint>
Of course there are still pain points of unit testing code that is injected with Bundle, BundleContext or BlueprintContainer objects. But even then blueprint offers benefits in that the BundleContext does not have to be carefully passed from the Activator through layers of objects to wherever it is needed.
>
> 2. Slide #8 For integration of blueprint with jta/jpa aries specific namespaces are used.
> xmlns:jta="http://aries.apache.org/xmlns/transactions/v1.0.0"
> xmlns:jpa="http://aries.apache.org/xmlns/jpa/v1.0.0"
>
> Are there plans to include it in specification? Why doesn’t the spec address integration with blueprint? (which is also covered by the spec).
As far as I understand blueprint extension namespace were originally part of the blueprint spec but were dropped fairly late in the day due to technical issues.
I would expect that some of these extensions might be tackled in a future revision of the EEG spec.
>
> Best regards,
> Lukasz
>