questions to Overview.ppt

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

questions to Overview.ppt

Lichota, Lukasz

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?

 

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

 

Reply | Threaded
Open this post in threaded view
|

Re: questions to Overview.ppt

Valentin Mahrwald
<base href="x-msg://12/">Hi Lukasz, 

comments below :)

Valentin

On 17 May 2010, at 13:36, Lichota, Lukasz wrote:

 
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.
 
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
 

Reply | Threaded
Open this post in threaded view
|

Re: questions to Overview.ppt

Bartosz Kowalewski
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
>>  
>
Reply | Threaded
Open this post in threaded view
|

RE: questions to Overview.ppt

Lichota, Lukasz
In reply to this post by Valentin Mahrwald
<base href="x-msg://12/">

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:[hidden email]]
Sent: Monday, May 17, 2010 9:51 PM
To: [hidden email]
Subject: Re: questions to Overview.ppt

 

Hi Lukasz, 

 

comments below :)

 

Valentin

 

On 17 May 2010, at 13:36, Lichota, Lukasz wrote:



 

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.

 

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

 

 

Reply | Threaded
Open this post in threaded view
|

Re: questions to Overview.ppt

Jeremy Hughes
On 18 May 2010 08:22, Lichota, Lukasz <[hidden email]> 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:[hidden email]]
> Sent: Monday, May 17, 2010 9:51 PM
> To: [hidden email]
> 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
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

RE: questions to Overview.ppt

Lichota, Lukasz
> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Jeremy Hughes
Sent: Tuesday, May 18, 2010 12:50 PM
To: [hidden email]
Subject: Re: questions to Overview.ppt

On 18 May 2010 08:22, Lichota, Lukasz <[hidden email]> 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:[hidden email]]
> Sent: Monday, May 17, 2010 9:51 PM
> To: [hidden email]
> 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
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: questions to Overview.ppt

Jeremy Hughes
On 18 May 2010 13:30, Lichota, Lukasz <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Jeremy Hughes
> Sent: Tuesday, May 18, 2010 12:50 PM
> To: [hidden email]
> Subject: Re: questions to Overview.ppt
>
> On 18 May 2010 08:22, Lichota, Lukasz <[hidden email]> 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:[hidden email]]
>> Sent: Monday, May 17, 2010 9:51 PM
>> To: [hidden email]
>> 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
>>
>>
>>
>>
>