Re: JPA 2.2 support

[Timothy Ward]

To my knowledge this hasn’t been done yet. It shouldn’t be a big job to add it 
if you wanted to submit a patch.

All the best,

Tim

> On 22 May 2019, at 16:16, Andrei Shakirin  wrote:
> 
> Hi,
> 
> Does Aries support JPA 2.2 specification?
> 
> I am trying to install Hibernate 5 under Karaf 4 with Aries JPA 2.7.2 
> features.
> The Hibernate versions 5.2.X (JPA 2.1) are working, but I have an issue with 
> installing Hibernate 5.3.X, 5.4.X  (JPA 2.2).
> 
> Regards,
> Andrei.
> 
> As a recipient of an email from Talend, your contact personal data will be on 
> our systems. Please see our contacts privacy notice at Talend, Inc. 
> 
> 
> 

Re: Jax-RS Whiteboard and OpenAPI

[Timothy Ward]

Hi,

To my knowledge nobody has done this in a reusable way yet, but if you’re 
interested in doing so then adding it as a project in the integrations would be 
great!

Tim


> On 18 Jun 2019, at 13:07, Oliver Schweitzer  wrote:
> 
> Hi,
> 
> I’m successfully using the Jax-RS Whiteboard in Karat 4.2, however one of the 
> last missing puzzle pieces to complete component bliss is integration of 
> OpenAPI (Swagger 2) - so that annotated (sub) resources get published as an 
> API schema by a Jax-RS Resource. 
> 
> Here 
> https://github.com/swagger-api/swagger-core/wiki/Swagger-2.X---Integration-and-configuration
>  is a plethora of information on how to integrate OpenAPI into various Jax-RS 
> setups, and if I look at it long enough I’ll probably work something out for 
> myself, but I’d like to know:  
> 
> Have some Aries Whiteboard users/devs done the integration 
> successfully/cleanly/easily?
> What would be the most OSGi/Declarative Service-like ways to integrate 
> OpenAPI into the Whiteboard mechanism? 
> Would one of these ways be a candidate for  a reference implementation here 
> https://github.com/apache/aries-jax-rs-whiteboard/tree/master/integrations ?
> 
> Regards,
> 
> Oliver

Re: Aries JAXRS whiteboard question

[Timothy Ward]

Hi,

I feel that the best place to ask this question would be the Apache Aries mail 
list (given that it’s an Aries project).  I’m therefore cross posting this back 
to the Aries list.

In general repackaging a library is intended to shield users from the 
underlying implementation details. In the case of the JAX-RS whiteboard it 
shouldn’t matter whether it’s CXF, Jersey, Restlet, or whatever else under the 
covers. In the specific case of Aries JAX-RS it proved necessary to put in some 
custom extensions to:


  1.  Get CXF to correctly apply lifecycle to the services that it uses
  2.  Get CXF to natively handle OSGi promises (this involves putting extra 
code in CXF client packages)
  3.  Avoid some lifecycle issues when CXF was incompletely installed

The overall Aries JAX-RS whiteboard project is first and foremost an 
implementation of the OSGi JAX-RS whiteboard specification (it’s the reference 
implementation) so item 2 was already a pretty hard requirement for repackaging 
CXF. Ease of use was a further concern, CXF is big, and does a lot more than 
just JAX-RS which pushed us into building “one bundle that works” rather than 
“a bundle with lots of CXF dependencies that are hard to manage and partially 
redundant”.

Could that be a hinderance around CXF version upgrades when used in a project? 
Such as if there was a security vulnerability in the version of CXF that was 
repackaged?

Aries JAX-RS is updated and released regularly. If there’s a security fix then 
rolling it out in a point release would be trivial (update a pom property and 
re-build). I therefore don’t see this as a significant problem.

 CXF works fine in OSGi, why wouldn't is just be pulled as is?

CXF *mostly* works fine in OSGi. We needed to add this support 
https://github.com/apache/aries-jax-rs-whiteboard/tree/master/jax-rs.whiteboard/src/main/java/org/apache/cxf/jaxrs/client
 and also to customise the way in which the CXF invocations occur (including 
the resource lifecycle) 
https://github.com/apache/aries-jax-rs-whiteboard/tree/master/jax-rs.whiteboard/src/main/java/org/apache/aries/jax/rs/whiteboard/internal/cxf

The end result is that embedding CXF gives better control over what’s used and 
tested (we have fixed a bunch of CXF bugs as part of building the whiteboard!) 
and is more reliable for our users.

Is this mainly meant for people who really don't care what is used under the 
covers and the version of it, but just want to quickly get a rest server up and 
going?

No, this is intended to be a production quality implementation of the OSGi 
JAX-RS Whiteboard specification. The fact that CXF is used is technically an 
implementation detail, but there is a fragment that you can attach to export 
the CXF packages from the Aries whiteboard if you have a desire to go CXF 
native. Using the plain JAX-RS API is the preferred option.

I hope this helps,

Tim

On 16 Jun 2019, at 16:00, Ryan Moquin 
mailto:fragility...@gmail.com>> wrote:

I was looking at the Aries JAXRS whiteboard example to see how it differs from 
just using CXF directly.  It looks interesting.  My one main concern would be 
around the Aries whiteboard bundle needing to repackage cxf dependencies.  
Could that be a hinderance around CXF version upgrades when used in a project?  
Such as if there was a security vulnerability in the version of CXF that was 
repackaged?  CXF works fine in OSGi, why wouldn't is just be pulled as is?  Is 
this mainly meant for people who really don't care what is used under the 
covers and the version of it, but just want to quickly get a rest server up and 
going?

Thanks!
Ryan

Re: Aries Async Service and Timeouts

[Timothy Ward]

Hi Sebastian,


Maybe some feature of Async that i missed?

For the moment, no. The Aries Async project hasn’t had many calls for new 
functionality, and so it hasn’t been updated to support OSGi R7. The Promises 
support is mostly done, and with a day or two of effort I’m sure it would be 
back up to date.

I'm not sure if Aries Async uses the Promise API in a substitutable way, but 
the latest version of the Promise API has timeout methods [1].

If you did have access to the OSGi R7 API then this would be a much neater and 
easier way to deal with the timeout. Note that while this would implement the 
timeout from the client side, it would not actually cancel the running work

One option is simply to try to use the lastest Promise API along with Aries 
Async.

Unfortunately this won’t work because the Async implementation requires the use 
of Aries promises (supplying threads). This restriction would no longer be 
necessary with Promises 1.1 because of the PromiseFactory, but this would 
require some more (again not huge amounts) work in the Async impl.


A suggestion that would work with the current impl is as follows:


// Create mediator, to call service asynchronously, both this and the Executor 
should be
// cached and reused if possible.
IMyService mediated = asyncService.mediate(myService, IMyService.class);


ScheduledExecutorService ses = Executors.newSingleThreadScheduledExecutor();


// Call service asynchronously
Promise promise = asyncService.call(mediated.process());

// Create a holder for our “timeout” result
Deferred d = new Deferred<>();

// Register the timeout
final ScheduledFuture sf = ses.schedule(
() -> d.fail(new TimeoutException("Timeout exceeded”), 100, 
TimeUnit.MILLISECONDS);

// Clean up the timeout if we resolve first
promise.onResolve(() -> sf.cancel(false));

// Resolve with the real result if it beats the timeout.
d.resolveWith(promise);

// This is the promise that will fail if there is a timeout or succeed if not
Promise promiseWithTimeout = d.getPromise();


The whole thing would clearly be simpler if some updates were made to the Aries 
Async Service implementation. If anyone has the time to make a patch then I’d 
be happy to review it!

Best Regards,

Tim
On 25 Jan 2019, at 16:02, Raymond Auge 
mailto:raymond.a...@liferay.com>> wrote:



On Fri, Jan 25, 2019 at 10:15 AM Benjamin Edwards 
mailto:edwards.b...@gmail.com>> wrote:
I'd also suggest that blocking the thread either by polling in a loop or using 
a dedicated timeout method is somewhat antithetical to the point of an 
asynchronous call. Better usually to do something like resolve a promise either 
with the service result or an exception after a threshold. This allows you to 
chain promises together nicely without blocking but also keeps things ticking 
along. It seems a shame that OSGi promises don't support a notion of 
cancellation (which is helpful when racing a long running call with a timeout).

If you have access to the deferred that the promise came from you can "cancel" 
by self-resolving using:

org.osgi.util.promise.Deferred.resolveWith(Promise)

See org.osgi.util.promise.Promises for handy factory methods you can pair that 
with to get the effect you want, a failure or success with a value.

- Ray


Can't have everything I guess.

Ben

On Fri, 25 Jan 2019, 2:58 pm Raymond Auge, 
mailto:raymond.a...@liferay.com>> wrote:
I'm not sure if Aries Async uses the Promise API in a substitutable way, but 
the latest version of the Promise API has timeout methods [1].

Perhaps Tim Ward could shed some light on this?
One option is simply to try to use the lastest Promise API along with Aries 
Async.

Sincerely,
- Ray

[1] 
https://osgi.org/specification/osgi.cmpn/7.0.0/util.promise.html#util.promise-timing.methods

On Fri, Jan 25, 2019 at 7:07 AM Lorr, Sebastian 
mailto:sebastian.l...@its-digital.de>> wrote:
Hi there,


I want to call a Service and wait for a given time for a response.

So I did a async servicecall like this:



// Create mediator, to call service asynchronously

IMyService mediated = asyncService.mediate(myService, IMyService.class);



// Call service and await promise to be fulfilled

Promise promise = asyncService.call(mediated.process());

boolean timeoutExceeded = false;

long startTime = Calendar.getInstance().getTimeInMillis();



serviceTimeoutMillis = 100;

// Wait until timeout for promise to be done

while (!promise.isDone()) {

Thread.sleep(10);

if (Calendar.getInstance().getTimeInMillis() > startTime + 
serviceTimeoutMillis) {

   timeoutExceeded = true;

   break;

}

}

if (timeoutExceeded) {
throw new TimeoutException("Timeout exceeded");
}





Now the question: is there a better way for waiting for promise-resolve until a 
given timeout?

Maybe some feature of Async that i missed?




Thanks in advance,



Sebastian

Re: JDK 11 support

[Timothy Ward]

This is something that will happen, but if you’re keen to muck in then patches 
are always welcome!

Tim

> On 17 Oct 2018, at 21:57, Andrei Shakirin  wrote:
> 
> Hi Aries,
> 
> Do you have any plans to support JDK 11 for all Aries subprojects (proxy, 
> jpa, transaction, jndi, etc)?
> 
> Regards,
> Andrei.
> As a recipient of an email from Talend, your contact personal data will be on 
> our systems. Please see our contacts privacy notice at Talend, Inc. 
> 
> 
> 

Re: Aries Transaction Control on Karaf 4.2.1

[Timothy Ward]

Hi,

Sorry for the delay. There really aren’t very many bundles that you need!

As seen in 
https://github.com/apache/aries-tx-control/blob/f7cd89eb49a99df841c3ab9c217dd678d5a18121/tx-control-providers/jpa/tx-control-jpa-itests/src/test/java/org/apache/aries/tx/control/itests/XAEclipseLink_2_6_0_Test.java#L41-L47,

EclipseLink needs:

mavenBundle("org.eclipse.persistence", "org.eclipse.persistence.jpa", "2.6.0”), 
mavenBundle("org.eclipse.persistence", "org.eclipse.persistence.core", 
"2.6.0”), mavenBundle("org.eclipse.persistence", "org.eclipse.persistence.asm", 
"2.6.0”), mavenBundle("org.eclipse.persistence", 
"org.eclipse.persistence.antlr", "2.6.0”), 
mavenBundle("org.eclipse.persistence", "org.eclipse.persistence.jpa.jpql", 
"2.6.0”), mavenBundle("org.apache.aries.jpa", 
"org.apache.aries.jpa.eclipselink.adapter", "2.4.0")

You will also need a transaction control service:

mavenBundle("org.apache.aries.tx-control", "tx-control-service-xa”)

A JPA resource provider:

mavenBundle("org.apache.aries.tx-control", "tx-control-provider-jpa-xa”)

A JPA Service implementation:

mavenBundle("org.apache.aries.jpa", "org.apache.aries.jpa.container”)

The JPA API (with contract)

mavenBundle("org.apache.aries.jpa.javax.persistence", "javax.persistence_2.1”)

In addition you will need to have a working DataSourceFactory service for your 
chosen database, for example:

mavenBundle("com.h2database", "h2”)

If you want to have configuration driven resources then you will need Config 
Admin installed, and that should be everything that you need!

Tim


On 29 Sep 2018, at 17:18, Piero 
mailto:pierospine...@gmail.com>> wrote:

Hi,

is it possible to have the list of minimum bundles (and versions) required at 
run time for using EclipseLink JPA with Aries transaction control XA?

I got working that on Karaf 4.2.0 bat now I've got some conflict in 4.2.1 
so I would try to uninstall conflicting bundles and keep just the required ones.

Of course, if anyone have already faced the same problem, any help is welcome, 
even if this could be more matter fo Karaf forum (I apologize for that).

Thanks in advance

Piero Spinelli

Re: Aries 2.7.0 -> JPA 2.0 or 2.1?

[Timothy Ward]

The Aries JPA container is a flexible implementation designed to be used with a 
variety of JPA providers. It is tested across numerous versions of EclipseLink, 
Hibernate and OpenJPA. Some of these versions only support JPA 2.0 (OpenJPA 
only got JPA 2.1 support in June), as a result it can work with JPA 2.0 or JPA 
2.1.

Aries JPA correctly sets up its import ranges so that this can work without 
problems, however this also relies on the persistence provider (in this case 
Hibernate) to set up its import ranges appropriately as well. If they haven’t 
got it quite right then they can end up being allowed to wire to JPA 2.0 even 
though that’s not what they should be using.

As Karaf wants to use JPA 2.1 then the sensible thing to do here is to have a 
Karaf feature which exclude the JPA 2.0 API and only exposes JPA 2.1, which is 
what they do.

I hope that this clears things up.

Tim

On 24 Aug 2018, at 09:02, Nerriere, Christian 
mailto:christiannerri...@eaton.com>> wrote:


Hello,

I’m using Karaf 4.2 with Aries 2.7.0 and Hibernate 5.2.9.Final and when I run a 
persistence test (without pax-exam), I’ve the following error:

…
java.lang.NoSuchMethodError: 
javax.persistence.Table.indexes()[Ljavax/persistence/Index;
…

With the help of StackOverflow, I’ve understood that there was a dependency 
conflict between two libs defining the JPA spec 2.0 and 2.1. When running the 
test the maven dependencies are used to build the test classpath and it 
contains:
• org\apache\aries\jpa\javax\persistence\javax.persistence_2.0\2.7.0
• org\hibernate\javax\persistence\hibernate-jpa-2.1-api\1.0.0.Final

My question is: why does the Aries JPA container POM contain a dependency to 
JPA 2.0 
(http://central.maven.org/maven2/org/apache/aries/jpa/org.apache.aries.jpa.container/2.7.0/org.apache.aries.jpa.container-2.7.0.pom)
 while the Aries feature definition contains a reference to JPA 2.1 
(http://central.maven.org/maven2/org/apache/aries/jpa/jpa-features/2.7.0/jpa-features-2.7.0-features.xml)?

Thanks.

Christian N.





Eaton Industries (France) S.A.S ~ Siège social: 110 Rue Blaise Pascal, Immeuble 
Le Viséo - Bâtiment A Innovallée, 38330, Montbonnot-St.-Martin, France ~ Lieu 
d'enregistrement au registre du commerce: Grenoble ~ Numéro d'enregistrement: 
509 653 176 ~ Capital social souscrit et liberé:€ 16215441 ~ Numéro de TVA: 
FR47509653176

Re: Single Transaction across EntityManagers

[Timothy Ward]

Hi Kaja,

If there is one TX in a thread and if that thread happens to go across 
boundaries, they have to use the same TX.

This is exactly what Transaction Control does if you use the required method. 
Also your use case definitely requires you to use XA transactions. You have 
multiple persistence units therefore you have multiple database connections 
(even if they are to the same database) and so you require a distributed 
transaction.

I’m not sure whether Aries allowes Entities to be added/deleted (I don’t want 
updated case to be supported) after EMF is created. Any idea?

This is not supported at runtimeby JPA, so there’s nothing Aries (or OSGi) can 
do to help beyond uninstalling the old bundle and installing the new bundle.

Regards,

Tim


On 5 Jun 2018, at 12:02, Mohideen, Kaja (Nokia - IN/Chennai) 
mailto:kaja.mohid...@nokia.com>> wrote:

Hi Tim,

Thanks for responding.

I have seen TX Control Project in Aries website. But, that will need my code to 
explicit to do this TX management. I don’t have a case where I want one of my 
bundles have their “own” TX. If there is one TX in a thread and if that thread 
happens to go across boundaries, they have to use the same TX. So, I’m looking 
to make it tied with Std TX annotations.

Other option I can think of: A bundle with a PU and service (So, 1 PU for all 
my apps). All my other application bundles invoke the service to get their 
entities register with EMF. But, I’m not sure whether Aries allowes Entities to 
be added/deleted (I don’t want updated case to be supported) after EMF is 
created. Any idea?

// Kaja

From: Timothy Ward [mailto:timothyjw...@hotmail.com] On Behalf Of Timothy Ward
Sent: Tuesday, June 5, 2018 4:13 PM
To: user@aries.apache.org<mailto:user@aries.apache.org>
Subject: Re: Single Transaction across EntityManagers
Importance: High

Hello,

Have you considered using Aries Transaction Control to manage your 
transactions? This is a much more reliable way to deal with transactions that 
run across module boundaries, and it is much clearer which resources have 
“opted in” to the transaction.

Best Regards,

Tim

On 1 Jun 2018, at 06:39, Mohideen, Kaja (Nokia - IN/Chennai) 
mailto:kaja.mohid...@nokia.com>> wrote:

Hi,

I’m using Aries JPA (in Apache Karaf) for my application where different 
services (bundles) have their own PersistenceContexts and they use a single 
Datasource (XA) – everything works fine.

All my modules are connecting to a single Datasource, so I have switched to 
Non-XA DS; now the Transactions seems to be per module (EM) and they are not 
atomic across modules.

I understand that XA would have co-ordinated this earlier. But, is it possible 
to make them use a Single DS Connection/Transaction to achieve the same effect 
(like mark PersistenceUnits “extended” or some other technique). I have 
searched the Aries-JPA repo for mention of PersistenceContextType and found 
nothing ☹. So, not sure whether Aries JPA supports this and if so – how?

Any help is greatly appreciated.

// Kaja

Re: Single Transaction across EntityManagers

[Timothy Ward]

Hello,

Have you considered using Aries Transaction Control to manage your 
transactions? This is a much more reliable way to deal with transactions that 
run across module boundaries, and it is much clearer which resources have 
“opted in” to the transaction.

Best Regards,

Tim

On 1 Jun 2018, at 06:39, Mohideen, Kaja (Nokia - IN/Chennai) 
mailto:kaja.mohid...@nokia.com>> wrote:

Hi,

I’m using Aries JPA (in Apache Karaf) for my application where different 
services (bundles) have their own PersistenceContexts and they use a single 
Datasource (XA) – everything works fine.

All my modules are connecting to a single Datasource, so I have switched to 
Non-XA DS; now the Transactions seems to be per module (EM) and they are not 
atomic across modules.

I understand that XA would have co-ordinated this earlier. But, is it possible 
to make them use a Single DS Connection/Transaction to achieve the same effect 
(like mark PersistenceUnits “extended” or some other technique). I have 
searched the Aries-JPA repo for mention of PersistenceContextType and found 
nothing ☹. So, not sure whether Aries JPA supports this and if so – how?

Any help is greatly appreciated.

// Kaja

Re: Service Loader Mediator (spifly)

[Timothy Ward]

The best option is, of course, to avoid using ServiceLoader as far as possible 
and to use injection to obtain the services. This way your Java SE injection 
container can use ServiceLoader (or whatever else it wants) and you can use 
OSGi services when in OSGi…

Tim

On 18 May 2018, at 21:41, Raymond Auge 
> wrote:



On Thu, May 17, 2018 at 10:52 AM, David Bosschaert 
> wrote:
Yeah, thinking more about it, the way it uses a weaving hook it currently 
expects to be started before other bundles. Thanks @Pierre for reminding us of 
that!

I don't really like this ordering either though. Just a couple of thoughts from 
my side:
* if you use static weaving this problem goes away, as the woven classes are 
put inside the bundle - @Ray would static weaving be an option for you?

Static weaving means that you cannot reuse the bundle outside of OSGi. For 
instance, it would be great to contribute appropriate service loader mediator 
data to Java EE and like API artifacts. This metadata has no effect outside of 
OSGi, but when used in OSGi it makes the API behave appropriately which is 
great.

* with dynamic weaving it should be possible to enhance SPI Fly so that it can 
act on existing bundles by refreshing them. Would this make sense for this 
use-case?

I believe this is the approach I would prefer.

- Ray


Best regards,

David

On 17 May 2018 at 15:53, Raymond Auge 
> wrote:
On Thu, May 17, 2018 at 9:44 AM, Pierre De Rop 
> wrote:
Hi Ray, David;

I was thinking that the org.apache.aries.spifly.dynamic.bundle should be 
started before all other bundles ?
David, am I correct ? (see http://aries.apache.org/modules/spi-fly.html, in 
section "Use with Dynamic Weaving")

Pierre, got it! I missed that part. Thanks for letting me know. This makes a 
significant difference :)

It's too bad because the impl does try to retroactively operate on bundles. It 
just fails in some scenarios and succeeds in others, which is why I wasn't sure.

Sincerely,
- Ray


cheers
Pierre

On Thu, May 17, 2018 at 12:42 PM, Raymond Auge 
> wrote:
Ok, that's all I needed to hear. I'll file a bug report and try to make a test 
case.

Thanks,
- Ray

On Thu, May 17, 2018 at 1:24 AM, David Bosschaert 
> wrote:
Hi Ray,

Sounds like a bug to me. It shouldn't be restricted by start ordering. Would it 
be possible to file a bug?

Best regards,

David

On 16 May 2018 at 18:38, Raymond Auge 
> wrote:
Is the Service Loader Mediator known to be constrained by start ordering?

In other words, I'm finding that spifly is having issues when not "started" 
before other bundles that specify the requirements and or capabilities on 
osgi.serviceloader.

--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)




--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)




--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)




--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

Re: DS vs Blueprint

[Timothy Ward]

As with anything that uses the OSGi Service Registry properly, DS waits for a 
service to be available before activating a component which uses that service. 
This means that there is no configuration of startup order, and that there are 
no points when the graph is incomplete assuming that:

a) All other bundles correctly wait for service dependencies (many do this 
badly if they try to use the raw OSGi API)
b) All services are registered only when they are usable (again, this is hard 
when using the low level API)

I know a large number of DS users, none of them need to use start-up ordering 
to make DS work. The problems that do occur happen when libraries have poorly 
written OSGi code which does not use a container, and instead use the low level 
OSGi APIs incorrectly.

Regards,

Tim


On 2 Sep 2016, at 18:34, Brad Johnson 
<brad.john...@mediadriver.com<mailto:brad.john...@mediadriver.com>> wrote:

Yes but doesn't the independent start up order of DS require configuration of 
start up order?

On Fri, Sep 2, 2016 at 11:30 AM, Timothy Ward 
<timothyjw...@apache.org<mailto:timothyjw...@apache.org>> wrote:
Hi Brad,

> On 27 Aug 2016, at 17:45, Brad Johnson 
> <brad.john...@mediadriver.com<mailto:brad.john...@mediadriver.com>> wrote:
>
> While I understand the benefits of DS I'm wondering if it makes much 
> difference for end users. I mean if I were creating a library for commons, 
> XStream, Beanio or something else then it makes a lot of sense to expose it 
> via DS.
>
> But when creating end user bundles with Camel routes, beans, interfaces, and 
> OSGi services the service damping provided by blueprint seems like a positive 
> benefit in that one doesn’t have to worry about start up order.

Independence of startup ordering is a benefit of using OSGi services in general 
- it applies to DS, Blueprint, and anything else that uses the OSGi service 
registry properly. It has little to do with damping.

The service damping from blueprint is actually more harmful than helpful in 
many cases. As there is never any bean destruction or re-injection there is no 
way to guarantee that the object reference you hold actually points at 
anything. When combined with blueprint’s “block for a really long time” 
behaviour on missing references this can wreak havoc in your system. Optional 
services are really horrible in this model.

As things stand currently blueprint is most widely used for working with Camel. 
From what I can tell configuring Camel is horrible, and my understanding is 
that the main advantage of blueprint is that there is a huge amount of 
ready-built Camel integration available. If Camel had a nicer, container 
agnostic configuration mechanism then I would see little reason to choose 
blueprint over DS.

Regards,

Tim



>
> That's doubly true now that I've been working with pax-cdi and Camel.  I'd 
> say the development time is cut in half.  The OSGiSeriviceProvider (sp?) 
> annotation still uses blueprint proxies behind the scenes but I don't think 
> that's a problem.  What it does do is eliminate the need for all the XML 
> configuration which can result in typos and other issues.
>
> What are the views on this?
>
> Brad

Re: blueprint:cm multiple bundle but same config file

[Timothy Ward]

 If the bundle is running where it has a 
bundle context it instead fires up an OsgiServiceRegistry(don't recall the full 
name.) In that case you can't add your local beans.

I noted that there is a CompositeRegistry in the AbstractCamelRunner and 
perhaps that should always be the one used.  If one boots up and an OSGi 
service registry is created both it and the SimpleRegistry are added to the 
CompositeRegistry but one can access the SimpleRegistry in order to add one's 
local dependencies for Camel routes.

On Wed, Jul 13, 2016 at 3:34 AM, Timothy Ward 
<timothyjw...@apache.org<mailto:timothyjw...@apache.org>> wrote:
Hi Brad,

I’ve been watching this thread for a while, and you’ve finally managed to draw 
me in :)


On 12 Jul 2016, at 17:42, Brad Johnson 
<brad.john...@mediadriver.com<mailto:brad.john...@mediadriver.com>> wrote:

Guillaume,

I'm still using Blueprint and have found Camel/SCR to be a pain to work with.  
It provides no tangible benefit if one is using Blueprint for routes and 
dependency injection anyway as it simply introduces one more way of configuring 
things. It was interesting to read the other day that Christian seems to have 
the same impression of the complexity of SCR.  I remember when I first tried I 
thought it looked pretty cool but started running into problems.

So what you’re comparing here isn’t really apples with apples. A long way back 
Camel provided a bunch of Spring XML sugar to make configuring Camel simpler. 
This was obviously a good thing because setting up Camel was (and is) hard. To 
this day people still use the Spring syntax for building their Camel routes. 
OSGi blueprint was effectively a move by Spring to standardise the Spring DM 
container, and so unsurprisingly blueprint looks a lot like Spring. Some people 
did the work to port the Camel Spring configuration to OSGi blueprint, and 
that’s why Camel is easy to use in blueprint.

If someone actually spent some time putting together a nice integration with 
SCR then I’m sure that using SCR would be at least as easy as blueprint. The 
problem here is that relatively few SCR developers/users use Camel, and the 
ones that do are just told to “use blueprint”.

That DS is in its second generation and only now getting around to transactions 
is telling.  Either it has reached its natural boundaries and is now 
over-reaching or wasn’t full thought out.

DS is actually working on its fifth release, and transactions are nowhere to be 
seen. You may be referring to the Transaction Control specification, which is 
separate from DS. They can be used together very effectively, but you could 
equally use Transaction Control with blueprint.

DS is actually one of the “good citizens” of the DI world in that it 
deliberately does less in order to do it well. There’s no dependency proxying, 
no aspects, just the code that you wrote injected with some other code that 
someone wrote.

To me it's a component and service bootstrapping mechanism which represents a 
small portion of the world I work in - transforms, routing, EIPs, etc.  I've no 
reason to embrace it or deny it unless it either makes my job much easier or I 
can't live without it.  So far adding Camel SCR and DS into the middleware just 
results in one more thing I have to deal with.

This is a perfectly acceptable viewpoint. If the fundamental limitations of the 
blueprint model aren’t a problem for you then switching right now is almost 
certainly unnecessary.


I think Blueprint works well these days and has come a long way in the past 3 
years.  The Aries team is to be commended for some great work.

Aries Blueprint has had a lot of extensions and improvements over the last 
three years. Sadly the same cannot be said for the specifications or other 
implementations. Aries Blueprint is very much the last implementation standing, 
and there has been no effort to standardise the new features (or even to try 
fixing the problems with the original standard). The set of RFPs/RFCs for 
blueprint that have been sitting idle in the OSGi Alliance is very telling.

As far as Aries blueprint is concerned, the main reason that it is still alive 
seems to be the fact that it was included in Karaf, and that Karaf provides 
Camel integration alongside it. Even Karaf itself is starting to move to use DS 
internally, offering blueprint as something for applications to use.


I’ve been surprised by the near religious zeal of some of the DS advocates.

Most OSGi developers I know (myself included) who really start to use DS 
consider it to be roughly equivalent to magic. The fact that the model can be 
as simple as it is and yet still flexible, correct and safe is both surprising 
and pleasing. Moving back to “not DS” is usually pretty painful and reminds 
people why they love DS so much.

I'll be interested in seeing the DS semantics and proxies for CDI. Heh. Proxies 
are another technology that I don't care about one way or the other as long as 
thi

Re: Can't get MySQL non-jta connection pool with Aries-2.4.0 and EL-2.6.2 working - Looking for (more) example(s).

[Timothy Ward]

Hi Erwin,

Sent from my iPhone

> On 25 Jul 2016, at 15:18, Erwin Hogeweg  wrote:
> 
> Hi Tim,
> 
>> Have you considered using Aries Transaction Control?
> I definitely have, that was going to be my next step once I got this working. 
> I just can’t stand that I can’t figure this out. It is not rocket science 
> IMHO ;-)

Actually, it sort of is. The number of different services involved gets large 
very quickly! This is one of the reasons that the OSGi RFC for Transaction 
Control exists.

> 
>> It's typically much simpler to configure than the raw JDBC service, and it 
>> definitely gives you connection pooling (again, without extra moving parts).
> Thanks. I might bite the bullet and skip ahead to Aries Transactions. Would 
> have been nice to have a working platform as baseline.

Transaction Control still needs you to use JPA persistence bundles (i.e. 
Meta-Persistence) but it simplifies everything else a lot. You can configure 
your EntityManager with just a few config admin properties.

Tim

> 
> Erwin
> 
>> 
>> Best Regards,
>> 
>> Tim Ward
>> 
>> Sent from my iPhone
>> 
>> On 24 Jul 2016, at 21:51, Erwin Hogeweg 
>> > wrote:
>> 
>> Hi,
>> 
>> Not sure if this is a question for these lists or for the EL list but I 
>> figure I start here. Feel free to redirect when you feel it doesn’t belong 
>> here.
>> 
>> I am trying to get a non-jta connection pool (internal connection pool) 
>> working with EL 2.6.2, Aries 2.4.0 (incl. EL adapter), dbcp2-2.1 and mySQL, 
>> but I must be missing something because I just can’t get it to work 
>> properly. Everything works just fine w/o a connection pool, so this is 
>> definitely the source of the misery.
>> 
>> Been struggling with this for a while now, and I am running out of ideas. I 
>> think I could use some sample code to point me in the right direction that 
>> doesn't use Blueprint? I found some of Christian’s examples, but I don’t 
>> think they are using connection pools.
>> 
>> Below a short summary of what I run into.
>> 
>> When I am using the ‘original’ MysqlDataSource...
>> 
>>   private DataSource createMySQLDataSource( Dictionary 
>> dbConnProps ) {
>>   MysqlDataSource ds = new MysqlDataSource();
>>   ds.setUrl( dbConnProps.get( "jdbc_url" ) );
>>   ds.setUser( dbConnProps.get( "jdbc_user" ) );
>>   ds.setPassword( dbConnProps.get( "jdbc_password" ) );
>>   return ds;
>>   }
>> 
>> … everything kinda works normally. The DataSource, PersistenceProvider and 
>> EntityManagerFactory are all created and registered correctly;
>> 
>> g! services javax.sql.DataSource
>> {javax.sql.DataSource}={eclipselink.target-database=MySQL, 
>> osgi.jndi.service.name=jdbc/mynonjta, service.id=139, service.bundleid=104, 
>> service.scope=singleton}
>> "Registered by bundle:" 
>> com.my.project.persistence.mysqldatasource_4.0.0.SNAPSHOT [104]
>> 
>> g! services javax.persistence.EntityManagerFactory
>> {javax.persistence.EntityManagerFactory}={osgi.unit.version=4.0.0.SNAPSHOT, 
>> osgi.unit.name=my.pu, 
>> osgi.unit.provider=org.eclipse.persistence.jpa.PersistenceProvider, 
>> service.id=142, service.bundleid=98, service.scope=singleton}
>> "Registered by bundle:" com.my.project.model_4.0.0.SNAPSHOT [98]
>> 
>> The performance is horrible though as I don’t really seem to get a 
>> connection pool. The connection is closed after every query. On top of that 
>> I loose all network connections every few seconds with a:
>> 
>> com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link 
>> failure
>> 
>> Which has me puzzled for a while now.
>> 
>> So my next attempt was to use the org.apache.commons.dbcp2.BasicDataSource:
>> 
>>  private DataSource createMySQLDataSource(  Dictionary 
>> dbConnProps ) {
>> 
>>   BasicDataSource basicDataSource = new BasicDataSource();
>>   basicDataSource.setDriverClassName("com.mysql.jdbc.Driver");
>> ...
>>   return basicDataSource;
>>   }
>> 
>> This fails because the following exception:
>> 
>> [EL Severe]: 2016-07-24 
>> 14:41:55.872--java.lang.UnsupportedOperationException: Not supported by 
>> BasicDataSource
>> at 
>> org.apache.commons.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1552)
>> 
>> Which is this method:
>> 
>>   @Override
>>   public Connection getConnection(String user, String pass) throws 
>> SQLException {
>>   // This method isn't supported by the PoolingDataSource returned by
>>   // the createDataSource
>>   throw new UnsupportedOperationException("Not supported by 
>> BasicDataSource");
>>   }
>> 
>> So I figured I create a version with a PoolingDataSource  (following the 
>> PoolingDataSourceExample in svn):
>> 
>>   ConnectionFactory connectionFactory = new 
>> DriverManagerConnectionFactory(dbConnProps.get( "jdbc_url" ), "user", 
>> "password");
>>   PoolableConnectionFactory poolableConnectionFactory = new 
>> 

Re: Can't get MySQL non-jta connection pool with Aries-2.4.0 and EL-2.6.2 working - Looking for (more) example(s).

[Timothy Ward]

Hi,

Have you considered using Aries Transaction Control? It's typically much 
simpler to configure than the raw JDBC service, and it definitely gives you 
connection pooling (again, without extra moving parts).

Best Regards,

Tim Ward

Sent from my iPhone

On 24 Jul 2016, at 21:51, Erwin Hogeweg 
> wrote:

Hi,

Not sure if this is a question for these lists or for the EL list but I figure 
I start here. Feel free to redirect when you feel it doesn’t belong here.

I am trying to get a non-jta connection pool (internal connection pool) working 
with EL 2.6.2, Aries 2.4.0 (incl. EL adapter), dbcp2-2.1 and mySQL, but I must 
be missing something because I just can’t get it to work properly. Everything 
works just fine w/o a connection pool, so this is definitely the source of the 
misery.

Been struggling with this for a while now, and I am running out of ideas. I 
think I could use some sample code to point me in the right direction that 
doesn't use Blueprint? I found some of Christian’s examples, but I don’t think 
they are using connection pools.

Below a short summary of what I run into.

When I am using the ‘original’ MysqlDataSource...

private DataSource createMySQLDataSource( Dictionary 
dbConnProps ) {
MysqlDataSource ds = new MysqlDataSource();
ds.setUrl( dbConnProps.get( "jdbc_url" ) );
ds.setUser( dbConnProps.get( "jdbc_user" ) );
ds.setPassword( dbConnProps.get( "jdbc_password" ) );
return ds;
}

… everything kinda works normally. The DataSource, PersistenceProvider and 
EntityManagerFactory are all created and registered correctly;

g! services javax.sql.DataSource
{javax.sql.DataSource}={eclipselink.target-database=MySQL, 
osgi.jndi.service.name=jdbc/mynonjta, service.id=139, service.bundleid=104, 
service.scope=singleton}
  "Registered by bundle:" 
com.my.project.persistence.mysqldatasource_4.0.0.SNAPSHOT [104]

g! services javax.persistence.EntityManagerFactory
{javax.persistence.EntityManagerFactory}={osgi.unit.version=4.0.0.SNAPSHOT, 
osgi.unit.name=my.pu, 
osgi.unit.provider=org.eclipse.persistence.jpa.PersistenceProvider, 
service.id=142, service.bundleid=98, service.scope=singleton}
  "Registered by bundle:" com.my.project.model_4.0.0.SNAPSHOT [98]

The performance is horrible though as I don’t really seem to get a connection 
pool. The connection is closed after every query. On top of that I loose all 
network connections every few seconds with a:

com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link 
failure

Which has me puzzled for a while now.

So my next attempt was to use the org.apache.commons.dbcp2.BasicDataSource:

   private DataSource createMySQLDataSource(  Dictionary 
dbConnProps ) {

BasicDataSource basicDataSource = new BasicDataSource();
basicDataSource.setDriverClassName("com.mysql.jdbc.Driver");
...
return basicDataSource;
}

This fails because the following exception:

[EL Severe]: 2016-07-24 14:41:55.872--java.lang.UnsupportedOperationException: 
Not supported by BasicDataSource
at 
org.apache.commons.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1552)

Which is this method:

@Override
public Connection getConnection(String user, String pass) throws 
SQLException {
// This method isn't supported by the PoolingDataSource returned by
// the createDataSource
throw new UnsupportedOperationException("Not supported by 
BasicDataSource");
}

So I figured I create a version with a PoolingDataSource  (following the 
PoolingDataSourceExample in svn):

ConnectionFactory connectionFactory = new 
DriverManagerConnectionFactory(dbConnProps.get( "jdbc_url" ), "user", 
"password");
PoolableConnectionFactory poolableConnectionFactory = new 
PoolableConnectionFactory(connectionFactory, null);
ObjectPool connectionPool = new 
GenericObjectPool<>(poolableConnectionFactory);
poolableConnectionFactory.setPool(connectionPool);
PoolingDataSource dataSource = new 
PoolingDataSource<>(connectionPool);
return dataSource;

But that still gives me an exception:

[EL Severe]: 2016-07-24 16:40:30.392--java.lang.UnsupportedOperationException
at 
org.apache.commons.dbcp2.PoolingDataSource.getConnection(PoolingDataSource.java:156)

So I am kinda lost now.

This is the relevant stuff from the persistence.xml file:

osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jdbc/mynonjta)











Although I only see one DataSource registered it somehow feels like there is 
some more stuff going on behind the (EL?) scenes that I don’t have a handle on 
yet.

BTW... I have also created an org.apache.aries.jpa.my.pu.cfg configuration 
file, but when I leave the DB properties out of the persistence.xml I get bunch 
of ClassNotFound exceptions, so that is suspicious.

BTW2… the examples link at the bottom of this page is broken: 

Re: blueprint:cm multiple bundle but same config file

[Timothy Ward]

Hi Brad,

I’ve been watching this thread for a while, and you’ve finally managed to draw 
me in :)


On 12 Jul 2016, at 17:42, Brad Johnson 
> wrote:

Guillaume,

I'm still using Blueprint and have found Camel/SCR to be a pain to work with.  
It provides no tangible benefit if one is using Blueprint for routes and 
dependency injection anyway as it simply introduces one more way of configuring 
things. It was interesting to read the other day that Christian seems to have 
the same impression of the complexity of SCR.  I remember when I first tried I 
thought it looked pretty cool but started running into problems.

So what you’re comparing here isn’t really apples with apples. A long way back 
Camel provided a bunch of Spring XML sugar to make configuring Camel simpler. 
This was obviously a good thing because setting up Camel was (and is) hard. To 
this day people still use the Spring syntax for building their Camel routes. 
OSGi blueprint was effectively a move by Spring to standardise the Spring DM 
container, and so unsurprisingly blueprint looks a lot like Spring. Some people 
did the work to port the Camel Spring configuration to OSGi blueprint, and 
that’s why Camel is easy to use in blueprint.

If someone actually spent some time putting together a nice integration with 
SCR then I’m sure that using SCR would be at least as easy as blueprint. The 
problem here is that relatively few SCR developers/users use Camel, and the 
ones that do are just told to “use blueprint”.

That DS is in its second generation and only now getting around to transactions 
is telling.  Either it has reached its natural boundaries and is now 
over-reaching or wasn’t full thought out.

DS is actually working on its fifth release, and transactions are nowhere to be 
seen. You may be referring to the Transaction Control specification, which is 
separate from DS. They can be used together very effectively, but you could 
equally use Transaction Control with blueprint.

DS is actually one of the “good citizens” of the DI world in that it 
deliberately does less in order to do it well. There’s no dependency proxying, 
no aspects, just the code that you wrote injected with some other code that 
someone wrote.

To me it's a component and service bootstrapping mechanism which represents a 
small portion of the world I work in - transforms, routing, EIPs, etc.  I've no 
reason to embrace it or deny it unless it either makes my job much easier or I 
can't live without it.  So far adding Camel SCR and DS into the middleware just 
results in one more thing I have to deal with.

This is a perfectly acceptable viewpoint. If the fundamental limitations of the 
blueprint model aren’t a problem for you then switching right now is almost 
certainly unnecessary.


I think Blueprint works well these days and has come a long way in the past 3 
years.  The Aries team is to be commended for some great work.

Aries Blueprint has had a lot of extensions and improvements over the last 
three years. Sadly the same cannot be said for the specifications or other 
implementations. Aries Blueprint is very much the last implementation standing, 
and there has been no effort to standardise the new features (or even to try 
fixing the problems with the original standard). The set of RFPs/RFCs for 
blueprint that have been sitting idle in the OSGi Alliance is very telling.

As far as Aries blueprint is concerned, the main reason that it is still alive 
seems to be the fact that it was included in Karaf, and that Karaf provides 
Camel integration alongside it. Even Karaf itself is starting to move to use DS 
internally, offering blueprint as something for applications to use.


I’ve been surprised by the near religious zeal of some of the DS advocates.

Most OSGi developers I know (myself included) who really start to use DS 
consider it to be roughly equivalent to magic. The fact that the model can be 
as simple as it is and yet still flexible, correct and safe is both surprising 
and pleasing. Moving back to “not DS” is usually pretty painful and reminds 
people why they love DS so much.

I'll be interested in seeing the DS semantics and proxies for CDI. Heh. Proxies 
are another technology that I don't care about one way or the other as long as 
things work well and don't require a lot of configuration.  So it’s great if we 
can get rid of proxies but not so great if I now have to trade that off for 
configuration of start up order on services to make sure everything is running 
before Camel routes come up.

Actually, this is one of the places where DS really shines. If you write a DS 
component properly (i.e. without trying to dig out of the DS lifecycle) then 
startup ordering ceases to be an issue.

Again, someone with a little time and expertise would probably find that Camel 
+ DS can be a really effective solution. The problem is finding the person who 
has the time, expertise and 

Re: Aries installation requires Java 1.5?

[Timothy Ward]

Hi Rolf,

In Java 7 the way in which javac reports warnings changed. This broke projects 
using older versions of the maven compiler plugin (like Aries). The errors 
are actually warnings, and go away when using a newer maven compiler plugin. 
There's not much we can do about existing released versions I'm afraid.

Regards,

Tim

On 5 Nov 2013, at 11:45, rolf r...@august.de wrote:

 The installation procedure 
 http://aries.apache.org/development/buildingaries.html does not list a 
 Prereqs for a specific Java version or vendor. I do appriciate that.
 
 However, wenn I follow the instructions I got errors indication that 
 -source=1.5 is required. See http://paste.debian.net/64050/.
 
 As I do not think to be the first to install Aries, where is my mistake?
 
 -- 
 mit freundlichen Grüßen, kind regards
 
 
 Rolf Schumacher

RE: Aries JTA, JPA, and SCR

[Timothy Ward]

Hi Philipp,
Declarative Services is designed to be an ultra-lightweight injection runtime, 
and so it doesn't include the proxying/interception capabilities necessary to 
support Declarative Qualities of Service like transactions. This is one of the 
primary drivers for choosing blueprint over DS.
There are annotations for managing transactions in Aries blueprint. These are 
contained in the latest (1.0.1) release of 
org.apache.aries.transaction.blueprint.
You can enable annotation support with the following:
blueprint  xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:tx=http://aries.apache.org/xmlns/transactions/v1.2.0;

tx:enable-annotations/

bean id=top class=org.apache.aries.transaction.pojo.AnnotatedPojo/
/blueprint
I hope this helps!
Tim Ward
---
Apache Aries PMC member  Enterprise OSGi advocate
Enterprise OSGi in Action (http://www.manning.com/cummins)
---


Date: Thu, 18 Jul 2013 23:00:37 +0200
Subject: Aries JTA, JPA, and SCR
From: smi...@googlemail.com
To: user@aries.apache.org

Hi,
I have a question related to JTA (in JPA) context and SCR:
Is it possible to use the container managed transactions also with SCR/DS? Or 
is this only possible via Blueprint?

Furthermore is there any Annotation support for the managing transactions or 
must this be done via the Blueprint XML?
CheersPhilipp 

RE: [Blueprint] how to set logging level ?

[Timothy Ward]

Hi,
The default configuration for the samples 
sets:org.ops4j.pax.logging.DefaultServiceLog.level=INFOThis can be changed to 
limit the output there. Otherwise you'll need to set the relevant SLF4J 
properties on your Eclipse run configuration.
I hope this helps.
Regards,
Tim Ward
---
Apache Aries PMC member  Enterprise OSGi advocate
Enterprise OSGi in Action (http://www.manning.com/cummins)
---


Date: Thu, 4 Jul 2013 09:34:18 +0200
Subject: Re: [Blueprint] how to set logging level ?
From: ch...@die-schneider.net
To: user@aries.apache.org

Can you try to also install and configure pax logging? It should allow you to 
define which logging categories are logged at what level.
Christian
Am 01.07.2013 23:22 schrieb Cristiano Gavião cvgav...@gmail.com:

Hello, 

When I running an application that is using Aries Blueprint inside Eclipse IDE 
I'm getting a bunch of log messages like this one in the console:

18:13:42.965 [Start Level Event Dispatcher] DEBUG 
o.a.a.b.container.BlueprintExtender - Found ProxyManager service, starting to 
process blueprint bundles



Could someone please teach me how could I set this off ?

thanks,

Cristiano

  

RE: BeanMetadata.getScope() returns null

[Timothy Ward]

A value of null means that the scope wasn't specified in the XML. We have to 
return null because in the blueprint specification the default scope of a bean 
is context specific. Top level beans default to being singleton. Inner beans 
default to being prototype. 
When we're parsing snippets we don't have that context information, so we have 
to return null.
Regards

Tim Ward
---
Apache Aries PMC member  Enterprise OSGi advocate
Enterprise OSGi in Action (http://www.manning.com/cummins)
---


 Date: Fri, 10 May 2013 07:05:09 -0700
 From: lich...@yahoo.com
 Subject: BeanMetadata.getScope() returns null
 To: user@aries.apache.org
 
 Hi
 When BeanMetadata.getScope() returns null, what is the scope of the bean?
 I'd have expected the method to always return the scope.
 The API is:
 
 /**
  * Return the scope for the bean.
  * 
  * @return The scope for the bean.
  * @see #SCOPE_SINGLETON
  * @see #SCOPE_PROTOTYPE
  */
 String getScope();
  

RE: Need Help: Handling multiple versions of same service

[Timothy Ward]

Do you want to pick just one of the services? Do you want access to both, but 
the option to choose which you use? Do you want the newer version to take 
precedence?

The solution Emily suggests ties your blueprint to a particular version of the 
service. This may be what you want, but it will prevent you from being able to 
use any other version of the service. If you actually want to be able to pick 
the service you use then you need to use a reference list, not a reference.

reference-list id=greetService  
   interface=com.mii.greet.Greet
   member-type=service-reference/ This object will be of 
type:ListServiceReferenceGreet You can compare the service properties of 
the Service References to work out which one you want to use.

Regards


Tim Ward
---
Apache Aries PMC member  Enterprise OSGi advocate
Enterprise OSGi in Action (http://www.manning.com/cummins)
---


Date: Mon, 21 Jan 2013 23:02:09 +
Subject: Re: Need Help: Handling multiple versions of same service
From: emijia...@googlemail.com
To: user@aries.apache.org

When you register the same service by a different versin of a bundle, you can 
specify a service property with a value (e.g. version=2.0) and then in your 
client bundle, you can search the service with filter attribute to get that 
matching service property.

reference id=accountRef  
   interface=org.apache.aries.simple.Account 
   component-name=”myAccount”
   filter=”(version=2.0)”/ 
Regards,
Emily
On Mon, Jan 21, 2013 at 1:11 PM, Jay Rajani jay.raj...@mobileinternet.co.in 
wrote:

Hi, 
I am using Apache Aries on Karaf OSGi container. I have two different version 
of a bundle installed at a time. I have exposed service using service tag as 
following.
 service ref=greetService interface=com.mii.greet.Greet  / 
On service consumer side, I refer to the service using reference tag. 
reference id=greetService interface=com.mii.greet.Greet /
 But on consumer side, I always receive the service provider from the bundle 
which exposes the service first. How can we refer to services provided by 
different versions of same bundle.
 Regards,Jay Rajani

-- 
Thanks
Emily
=

Emily Jiang
eji...@apache.org
  

RE: Aries eclipselink.adapter

[Timothy Ward]

Hi

The bit in brackets for the jndi name is an ldap filter (just like a service 
lookup). What you want is 

((osgi.jndi.service.name=jpa/jtaStagingDb)(xa=true))

You don't need to add   entry key=xa value=true / to your service 
export, that gets added by the transaction wrappers bundle when it re-exports 
your service (to let you know it's the wrapped one). 

I think the easiest setup for you is to use:

jta-data-sourceosgi:service/javax.sql.XADataSource/(osgi.jndi.service.name=jpa/jtaStagingDb)/jta-data-source


 service id=xaDataSource ref=stagingXADataSource
interface=javax.sql.XADataSource
service-properties
  entry key=osgi.jndi.service.name value=jpa/jtaStagingDb /
/service-properties
/service


Regards,

Tim

Date: Sat, 20 Oct 2012 21:29:53 +1030
From: a...@solveitsoftware.com
To: user@aries.apache.org
Subject: Re: Aries eclipselink.adapter


  

  
  
While you are still on-line, may I ask
  you for some clarifications;

  

  persistence.xml: the following apparently doesn't work:

  
jta-data-sourceosgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jpa/jtaStagingDb
  xa=true)/jta-data-source

  

  datasource blueprint? : neither this

   service id=xaDataSource ref=stagingXADataSource

  interface=javax.sql.DataSource

  service-properties

entry key=osgi.jndi.service.name
  value=jpa/jtaStagingDb /

entry key=xa value=true /

  /service-properties

/service

  

  

  What's the correct syntax?

  

  On 20/10/2012 9:25 PM, Timothy Ward wrote:



  
  I'm glad I could help!



I'll check with Manning about the discount code, I wasn't aware
that it had an expiry date.



Regards,



Tim



Date: Sat, 20 Oct 2012 21:08:05 +1030

From: a...@solveitsoftware.com

To: user@aries.apache.org

Subject: Re: Aries eclipselink.adapter



Hi, Timothy.

  

  Thank you, your message arrived very handy just when I am
  wasting my Saturday night (UTC +9.30) in another attempt to
  make JTA work.

  For a more than a couple of week I put it on the back burner,
  while doing other tasks.

  I will look at your suggestions and also will purchase the
  book - thanks for the generous offer. I had only green paper
  and the source code so far.

  So, I may want to ask for an autograph from the author :).

  

  My OSGi crash course is lasting couple of month by now, so I
  had only chance to digest (albeit still suffering heartburn :)
  ) OSGi in Action.

  Though I realized at rather early stage that I have to deal
  with OSGi enterprise as far as JPA/JTA container support
  concerned.

  

  Kind regards,

  Anatoly

  

  PS The coupon code you have entered has expired I
received this message when applied the code.



  

  On 20/10/2012 8:25 PM, Timothy Ward wrote:



  Hi,

I'm afraid I haven't had time to do a full review, but from
the log I see that your datasource services are both being
registered by blueprint using the DataSource interface. 



Unless you're enlisting the JTA datasource with transactions
yourself then this looks like the source of the problem. If
you want the Aries runtime to do the enlistment then you
need to register the datasource as an XADataSource. 



There are then two options:

1.  You can let the transaction wrappers bundle do the
enlistment and add (xa=true) to your JTA-data-source jndi
name



2. You can let the JPA container do the enlistment by
changing the JTA-data-source jndi name to use XADataSource
as the interface. This will only work for Aries JPA 1.0 and
higher.



If you are after more information about setting up OSGi
applications with JPA then there's a whole chapter about it
in Enterprise OSGi in Action, along with chapters about
tools, testing, web applications and remoting. You can get
it at http://www.manning.com/cummins
and get 37% off using the code eosgi37. 



I hope this helps you get set up ok.



Regards,



Tim



Date: Mon, 15 Oct 2012 01:55:59 +1030

From: a...@solveitsoftware.com

To: user@aries.apache.org

Subject: Re: Aries eclipselink.adapter



Thank you, Timothy

RE: Aries eclipselink.adapter

[Timothy Ward]

In which case it is starting to sound as though there might be a problem with 
the db driver. Have you tried it with derby or similar?

Tim

Date: Sun, 21 Oct 2012 00:49:14 +1030
From: a...@solveitsoftware.com
To: user@aries.apache.org
Subject: Re: Aries eclipselink.adapter


  

  
  
Yes.

  

  

  On 21/10/2012 12:48 AM, Timothy Ward wrote:



  
  This was in addition to changing your datasource
blueprint to:



 service id=xaDataSource ref=stagingXADataSource

interface=javax.sql.XADataSource

service-properties

  entry key=osgi.jndi.service.name
value=jpa/jtaStagingDb /

  /service-properties

/service



wasn't it?



Tim



Date: Sun, 21 Oct 2012 00:02:21 +1030

From: a...@solveitsoftware.com

To: user@aries.apache.org

Subject: Re: Aries eclipselink.adapter



... my progress so far :

  

  With this line in the persistence.xml

 
jta-data-sourceosgi:service/javax.sql.DataSource/(amp;(osgi.jndi.service.name=jpa/jtaStagingDb)(xa=true))/jta-data-source

  

  Yet, the result is still as before: all the participating
  transactions apart from the offending one got commited.

  

  My only choice is to MsSql, and the problem might be with the
  driver. 

  Of course, I might try to build the test case with other
  database to verify this. 

  

  As for the latest suggestions to tweak the config.ini ... This
  one is  generated (Eclipse default option: generate with
  default content) and

  doesn't bother to specify the
  org.osgi.framework.system.packages property.

  I definitely not going to create that listing manually - it's
  crazy.

  

  At this very moment I tend to point finger to MsSql ...

  

  Regards,

  Anatoly

  

  On 20/10/2012 10:43 PM, Timothy Ward wrote:



  Hi,



Have you set up your system packages to prevent people
getting wired to the split package in the JDK?



If you look at

https://svn.apache.org/repos/asf/aries/trunk/samples/blog/blog-assembly/src/main/filtered-resources/configuration/config.ini



You can see that the org.osgi.framework.system.packages
property sets a mandatory partial=true parameter on
javax.transaction and javax.transaction.xa



Regards,



Tim



Date: Sat, 20 Oct 2012 21:37:05 +1030

From: a...@solveitsoftware.com

To: user@aries.apache.org

Subject: Re: Aries eclipselink.adapter



I tried the option 2) - I
  recollect tried it some time before.

  And now it also doesn't work - problem with MsSql driver

  

  Caused by: java.lang.LinkageError: loader constraint
  violation in interface itable initialization: when
  resolving method
  
net.sourceforge.jtds.jdbcx.JtdsXAConnection.getXAResource()Ljavax/transaction/xa/XAResource;


  the class loader (instance of
  org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader)
  of the current class,
  net/sourceforge/jtds/jdbcx/JtdsXAConnection, and the class
  loader (instance of bootloader) for interface
  javax/sql/XAConnection have different Class objects for
  the type javax/transaction/xa/XAResource used in the
  signature

  at
net.sourceforge.jtds.jdbcx.JtdsDataSource.getXAConnection(JtdsDataSource.java:116)

  at
org.apache.aries.transaction.jdbc.XADatasourceEnlistingWrapper.getConnection(XADatasourceEnlistingWrapper.java:63)

  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
  Method)

  

  So, the ball on the MsSql driver side? The bad news is
  that I am not aware of any other driver, and that one
  worked perfectly well with Spring framework JTA
  declarative support in non-OSGi environment.

  

  What do you think?

  

  On 20/10/2012 9:25 PM, Timothy Ward wrote:



  I'm glad I could help!



I'll check with Manning about the discount code, I
wasn't aware that it had an expiry date.



Regards,



Tim



Date: Sat, 20 Oct 2012 21:08:05 +1030

From

RE: ReferenceRecipe waits although service is available again

[Timothy Ward]

I'm glad that you have a simple case working :)

The reason I wanted to see the manifests is that it sounds like you have an 
inconsistent class space, and the new implementation cannot be used without 
re-wiring the consumer. Does your service-providing bundle export any packages? 
If so does your service-consuming bundle import them? They don't have to be 
related to the service for it to start causing problems. 

Tim

Date: Mon, 23 Jul 2012 20:34:27 +0200
Subject: Re: ReferenceRecipe waits although service is available again
From: balazs.zsol...@everit.biz
To: user@aries.apache.org

Hi,
thank you for offering your help. I tried to create a more simple use case 
(with non-business logic bundles) however I could not reproduce the problem. 
This is good news as blueprint works :).

I will try to add every dependency we use in our system (hibernate, myfaces, 
...) and try to find the cause of the problem. If I can reproduce it but cannot 
find the cause I will prepare a sample application with a full testing 
environment (ready to use equinox with libraries inside). I will not have time 
in the following couple of days but I will get back to this.

If I find the cause I will drop a mail anyway to let others know what caused 
the hangs.
Thanks and regards,Balazs


On Fri, Jul 20, 2012 at 6:01 PM, Timothy Ward timothyjw...@apache.org wrote:




Hi,

Could you send the manifests of the three bundles, and the manifest of the 
updated core bundle? I'd like to check for class-space issues. 

Regards,

Tim

Date: Fri, 20 Jul 2012 10:20:25 +0200

Subject: ReferenceRecipe waits although service is available again
From: balazs.zsol...@everit.biz
To: user@aries.apache.org


Hi,
I have a problem. Please help me finding out if this is a bug or my use case is 
wrong.
There are three bundles:API bundle: Contains an interface A

Core bundle: Contains the implementation of A and provides it as a 
serviceServlet bundle:Contains Servlet classesContains a ServletActivator class 
that has init, destroy method and A property

A blueprint configuration that sets the A property in the ServletActivator and 
calls the init methodThe init method instantiates the servlet and passes it to 
org.osgi.service.http.HttpService

I start Equinox, everything is fine. I can see the servlet running well. I say 
an update command on the Core bundle and I see that the service is unregistered 
and registered again provided by this bundle. After an http request will stop 
at the line below until a timeout:


qtp1313052129-27 prio=6 tid=0x0873d800 nid=0x2498 in Object.wait() 
[0x1105d000]   java.lang.Thread.State: TIMED_WAITING (on object 
monitor)at java.lang.Object.wait(Native Method)

at 
org.apache.aries.blueprint.container.ReferenceRecipe.getService(ReferenceRecipe.java:202)
- locked 0x000782888a68 (a java.lang.Object)at 
org.apache.aries.blueprint.container.ReferenceRecipe.access$000(ReferenceRecipe.java:56)

at 
org.apache.aries.blueprint.container.ReferenceRecipe$ServiceDispatcher.call(ReferenceRecipe.java:290)
at 
Proxy18044d63_3609_456d_82b5_803c25785628.getCurrentPresenseForAdspace(Unknown 
Source)

at 
..MyServlet.service(MyServlet.java:76)
at 
org.eclipse.equinox.http.servlet.internal.ServletRegistration.handleRequest(ServletRegistration.java:90)

at 
org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:109)
at 
org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:67)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)

at 
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:598)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:486)   
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:229)

at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)   
 at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)

at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)   
 at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)

at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111) 
   at org.eclipse.jetty.server.Server.handle(Server.java:350)

at 
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454)
at 
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890

RE: ReferenceRecipe waits although service is available again

[Timothy Ward]

Hi,

Could you send the manifests of the three bundles, and the manifest of the 
updated core bundle? I'd like to check for class-space issues. 

Regards,

Tim

Date: Fri, 20 Jul 2012 10:20:25 +0200
Subject: ReferenceRecipe waits although service is available again
From: balazs.zsol...@everit.biz
To: user@aries.apache.org

Hi,
I have a problem. Please help me finding out if this is a bug or my use case is 
wrong.
There are three bundles:API bundle: Contains an interface A
Core bundle: Contains the implementation of A and provides it as a 
serviceServlet bundle:Contains Servlet classesContains a ServletActivator class 
that has init, destroy method and A property
A blueprint configuration that sets the A property in the ServletActivator and 
calls the init methodThe init method instantiates the servlet and passes it to 
org.osgi.service.http.HttpService
I start Equinox, everything is fine. I can see the servlet running well. I say 
an update command on the Core bundle and I see that the service is unregistered 
and registered again provided by this bundle. After an http request will stop 
at the line below until a timeout:

qtp1313052129-27 prio=6 tid=0x0873d800 nid=0x2498 in Object.wait() 
[0x1105d000]   java.lang.Thread.State: TIMED_WAITING (on object 
monitor)at java.lang.Object.wait(Native Method)
at 
org.apache.aries.blueprint.container.ReferenceRecipe.getService(ReferenceRecipe.java:202)
- locked 0x000782888a68 (a java.lang.Object)at 
org.apache.aries.blueprint.container.ReferenceRecipe.access$000(ReferenceRecipe.java:56)
at 
org.apache.aries.blueprint.container.ReferenceRecipe$ServiceDispatcher.call(ReferenceRecipe.java:290)
at 
Proxy18044d63_3609_456d_82b5_803c25785628.getCurrentPresenseForAdspace(Unknown 
Source)
at 
..MyServlet.service(MyServlet.java:76)
at 
org.eclipse.equinox.http.servlet.internal.ServletRegistration.handleRequest(ServletRegistration.java:90)
at 
org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:109)
at 
org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:67)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at 
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:598)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:486)   
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:229)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)   
 at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)   
 at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111) 
   at org.eclipse.jetty.server.Server.handle(Server.java:350)
at 
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454)
at 
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890)
at 
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:630)
at 
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230)at 
org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:77)
at 
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:620)
at 
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:46)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:603)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:538)

In two of my applications it is always reproducable. Please let me know if you 
see the problem based on the stacktrace by looking at it or if I should provide 
a sample applicaiton. It would be really nice to solve this before 1.0.0 
release comes out as this really stops our TDD development workflow.

There is another problem based on this:
If I update the Servlet bundle just after updating the core bundle everything 
works fine. However if I update the Core bundle, make an http request and than 
try updating the web bundle will be locked until the timeout (basically I 
cannot process any osgi related command in the container as a bundle 

RE: PersistenceDescriptorParserImpl and handling namespaces in persistence.xml

[Timothy Ward]

Hi Johan,

We always welcome patches and bugs! If you would like to contribute then the 
best way would be to raise a bug against the JPA component of Aries in JIRA 
http://issues.apache.org/jira - it would be great if you could include your 
test case, and even better if your patch includes unit tests to prevent it 
regressing in the future!

Regards,

Tim

From: johan.huylebro...@i8c.be
To: user@aries.apache.org
Date: Thu, 5 Jul 2012 08:31:29 +0200
Subject: PersistenceDescriptorParserImpl and handling namespaces in 
persistence.xml

Hello,I’m using aries-jpa 0.3 with service mix. If I use a persistence.xml 
where the elements are prefixed by a namespace as in:pers:persistence 
xmlns:pers=http://java.sun.com/xml/ns/persistence;   
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;   
xsi:schemaLocation=http://java.sun.com/xml/ns/persistence 
http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd;   version=1.0   
pers:persistence-unit name=alphapers:properties  pers:property 
name=javax.persistence.jdbc.driver value=alpha.db.class/  
pers:property name=javax.persistence.jdbc.url value=jdbc:alpha:url/  
pers:property name=javax.persistence.jdbc.user value=alan/  
pers:property name=javax.persistence.jdbc.password value=4l4n/
/pers:properties  /pers:persistence-unit /pers:persistence It is rejected 
by the PersistenceDescriptorParser, AFAIK using a prefix is valid and should be 
accepted. If it is indeed a bug and not ‘works as intended’ I believe it can 
easily be fixed by making the parser namespace-aware. I can send you a patch 
with tests if you are interested. Cheers, Johan Huylebroeck 
http://www.i8c.be/integr8-consulting

RE: Aries and fluent builders

[Timothy Ward]

All contributions are welcome!

I would imagine that the most practical approach would be to add a new 
namespace handler called fluent, builder or similar. This could be provided as 
a new bundle in the blueprint project.

Adding some XML along the lines of the following to your blueprint:

bean class=builderClass fluent:begin-method=getConfigurable 
fluent:end-method=create

  argument2/argument

  fluent:configure method=setJDBCURL value=someValue/
  fluent:configure method=autoCommit
  valuetrue/value
  fluent:configure method=addListener ref=someBeanId/
/bean


could result in a configured bean using a fluent API like

builderClass.getConfigurable(2).setJDBCURL(someValue).autoCommit(true).addListener(blueprintBean).create();

Under the covers the namespace handler can turn the bean metadata into a 
normal blueprint metadata tree like the really verbose XML I gave as an 
example before.

What do you think?

Regards,

Tim Ward
---
Apache Aries PMC member  Enterprise OSGi advocate
Enterprise OSGi in Action (http://www.manning.com/cummins)
---


From: l...@code-house.org
Subject: Re: Aries and fluent builders
Date: Thu, 15 Dec 2011 09:42:40 +0100
To: user@aries.apache.org



Timothy,If you could give an advice where to start, I can experiment. Maybe we 
can add an attribute from additional namespace (aries-util?) which will mark an 
field as non standard java bean and let inject given value? But, it is possible 
to extend a property behavior somehow?
Regards,LukaszWe could look at adding some better fluent support in Aries 
blueprint (although it would be in a non-standard namespace). It might be a 
while before there was anything actually in trunk though.

Regards

Tim Ward
---
Apache Aries PMC member  Enterprise OSGi advocate
Enterprise OSGi in Action (http://www.manning.com/cummins)
---


From: l...@code-house.org
Subject: Re: Aries and fluent builders
Date: Thu, 15 Dec 2011 09:26:37 +0100
To: user@aries.apache.org

Hey Timothy,I know that solution proposed by you will work but it will mess a 
XML. Once I'll need to inject more values I will have 100 lines only to put 
true or false in some fields.
Regards,Lukasz
Hi,

It's not very concise, but this should work:

bean id=processEngineConfiguration1 
class=org.activiti.engine.ProcessEngineConfiguration 
factory-method=createStandaloneInMemProcessEngineConfiguration/

bean id=processEngineConfiguration2 
factory-ref=processEngineConfiguration1 
factory-method=setDatabaseSchemaUpdate
  argument value=false/
/bean

bean id=processEngineConfiguration3 
factory-ref=processEngineConfiguration2 factory-method=setDataSource
  argument
bean class=org.h2.jdbcx.JdbcDataSource
  property name=url value=jdbc:h2:mem:activiti /
/bean
  /argument
/bean

bean id=processEngineConfiguration4 
factory-ref=processEngineConfiguration3 
factory-method=setJobExecutorActivate
  argument value=true/
/bean


bean id=processEngine factory-ref=processEngineConfiguration4 
factory-method=buildProcessEngine/
If you're interested in more information about advanced blueprint techniques 
then you may find Enterprise OSGi in Action to be a useful resource. You can 
get 37% off if you use the code eosgi37 at the Manning website - 
http://www.manning.com/cummins 

Regards,

Tim Ward
---
Apache Aries PMC member  Enterprise OSGi advocate
Enterprise OSGi in Action (http://www.manning.com/cummins)
---


From: l...@code-house.org
Subject: Aries and fluent builders
Date: Thu, 15 Dec 2011 08:58:47 +0100
To: user@aries.apache.org

Hello,I tried to use Aries instead of Spring to configure Activiti process 
engine. The problem I meet was related to fluent builders. Activiti can be 
configured with fluent builder, for example:
ProcessEngine processEngine = 
ProcessEngineConfiguration.createStandaloneInMemProcessEngineConfiguration()
  .setDatabaseSchemaUpdate(ProcessEngineConfiguration.DB_SCHEMA_UPDATE_FALSE)
  .setJdbcUrl(jdbc:h2:mem:my-own-db;DB_CLOSE_DELAY=1000)
  .setJobExecutorActivate(true)
  .buildProcessEngine();
I ported this fragment to an XML fragment:
bean id=processEngineConfiguration 
class=org.activiti.engine.impl.cfg.StandaloneInMemProcessEngineConfiguration 
   property name=jobExecutorActivate value=true /property 
name=databaseSchemaUpdate value=false /property 
name=dataSourcebean class=org.h2.jdbcx.JdbcDataSource
property name=url value=jdbc:h2:mem:activiti //bean 
   /property/beanbean id=processEngine 
factory-ref=processEngineConfiguration factory-method=buildProcessEngine   
 /bean
The error reported by blueprint 
is:org.osgi.service.blueprint.container.ComponentDefinitionException: No setter 
for jobExecutorActivate property
The jobExecutorActivate property returns an instance of 
ProcessEngineConfiguration so it is not a regular 

RE: Aries and fluent builders

[Timothy Ward]

Hi,

It's not very concise, but this should work:


bean id=processEngineConfiguration1 
class=org.activiti.engine.ProcessEngineConfiguration 
factory-method=createStandaloneInMemProcessEngineConfiguration/

bean id=processEngineConfiguration2 
factory-ref=processEngineConfiguration1 
factory-method=setDatabaseSchemaUpdate
  argument value=false/
/bean

bean id=processEngineConfiguration3 
factory-ref=processEngineConfiguration2 factory-method=setDataSource
  argument
bean class=org.h2.jdbcx.JdbcDataSource
  property name=url value=jdbc:h2:mem:activiti /
/bean
  /argument
/bean

bean id=processEngineConfiguration4 
factory-ref=processEngineConfiguration3 
factory-method=setJobExecutorActivate
  argument value=true/
/bean


bean id=processEngine factory-ref=processEngineConfiguration4 
factory-method=buildProcessEngine/

If you're interested in more information about advanced blueprint techniques 
then you may find Enterprise OSGi in Action to be a useful resource. You can 
get 37% off if you use the code eosgi37 at the Manning website - 
http://www.manning.com/cummins 

Regards,

Tim Ward
---
Apache Aries PMC member  Enterprise OSGi advocate
Enterprise OSGi in Action (http://www.manning.com/cummins)
---


From: l...@code-house.org
Subject: Aries and fluent builders
Date: Thu, 15 Dec 2011 08:58:47 +0100
To: user@aries.apache.org



Hello,I tried to use Aries instead of Spring to configure Activiti process 
engine. The problem I meet was related to fluent builders. Activiti can be 
configured with fluent builder, for example:
ProcessEngine processEngine = 
ProcessEngineConfiguration.createStandaloneInMemProcessEngineConfiguration()
  .setDatabaseSchemaUpdate(ProcessEngineConfiguration.DB_SCHEMA_UPDATE_FALSE)
  .setJdbcUrl(jdbc:h2:mem:my-own-db;DB_CLOSE_DELAY=1000)
  .setJobExecutorActivate(true)
  .buildProcessEngine();
I ported this fragment to an XML fragment:
bean id=processEngineConfiguration 
class=org.activiti.engine.impl.cfg.StandaloneInMemProcessEngineConfiguration 
   property name=jobExecutorActivate value=true /property 
name=databaseSchemaUpdate value=false /property 
name=dataSourcebean class=org.h2.jdbcx.JdbcDataSource
property name=url value=jdbc:h2:mem:activiti //bean 
   /property/beanbean id=processEngine 
factory-ref=processEngineConfiguration factory-method=buildProcessEngine   
 /bean
The error reported by blueprint 
is:org.osgi.service.blueprint.container.ComponentDefinitionException: No setter 
for jobExecutorActivate property
The jobExecutorActivate property returns an instance of 
ProcessEngineConfiguration so it is not a regular Java Bean property. Do you 
have any ideas how to manage both - Aries and Activiti to work together?
Best regards,Lukasz   

RE: Aries/OpenJPA strange error - A JDBC Driver or DataSource class name must be specified in the ConnectionDriverName?

[Timothy Ward]

Hi,

That's the error Open JPA gives you when the DataSource fails. This is probably 
because your JNDI lookup is failing. Is there a valid DataSource at 
jdbc/dupcheckcts ?

Regards,

Tim Ward
---
Apache Aries PMC member  Enterprise OSGi advocate
Enterprise OSGi in Action (http://www.manning.com/cummins)
---


Date: Mon, 21 Nov 2011 15:00:43 -0600
Subject: Aries/OpenJPA strange error - A JDBC Driver or DataSource class name 
must be specified in the ConnectionDriverName?
From: mattmadha...@gmail.com
To: user@aries.apache.org

Hello,I'm using Apache Aries 0.4 (from IBM WAS) and OpenJPA 2.1.1-SNAPSHOT also 
from IBM.
I have a data source defined in WAS: Jndi Name : jdbc/dupcheckcts

I have my persistence.xml as follows:
?xml version=1.0 encoding=UTF-8?persistence version=2.0 
xmlns=http://java.sun.com/xml/ns/persistence; 
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; 
xsi:schemaLocation=http://java.sun.com/xml/ns/persistence 
http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd;
persistence-unit name=DuCk_jpa transaction-type=JTA   
descriptionPersistence x/description

providerorg.apache.openjpa.persistence.PersistenceProviderImpl/provider 


jta-data-sourcejdbc/dupcheckcts/jta-data-source 
classcom..entity.Clx/class  
classcom..entity.Clxl/class
classcom..entity.Clxt/class 
classcom..entity.Clxx/class

..  propertiesproperty 
name=openjpa.Log value=DefaultLevel=TRACE, Runtime=TRACE, Tool=TRACE, 
SQL=TRACE /
property name=openjpa.RuntimeUnenhancedClasses 
value=unsupported /
property name=openjpa.Compatibility 
value=StrictIdentityValues=false //properties

When I deploy the EBA and  start the app I'm getting the following error:
Caused by: openjpa-2.1.1-SNAPSHOT-r422266:1141200 fatal user error 
org.apache.openjpa.persistence.ArgumentException: A JDBC Driver or DataSource 
class name must be specified in the ConnectionDriverName property.
at 
org.apache.openjpa.jdbc.schema.DataSourceFactory.newDataSource(DataSourceFactory.java:76)
at 
org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.createConnectionFactory(JDBCConfigurationImpl.java:844)
at 
org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.getDBDictionaryInstance(JDBCConfigurationImpl.java:602)
   at 
org.apache.openjpa.jdbc.meta.MappingRepository.endConfiguration(MappingRepository.java:1510)


Any ideas please?
Thanks in advance!
ThanksMatt

RE: Strange OpenJPA and BP problem

[Timothy Ward]

Hi Matt,

No fix, or proposed fix, yet. You should feel free to have a look. Also you 
could avoid packaging your entities separately from your persistence.xml. The 
JPA service specification states pretty clearly that packaging entities and 
persistence.xml in this way is not supported. If you avoid the packaging split 
then you will never hit this problem.

Regards

Tim Ward
---
Apache Aries PMC member  Enterprise OSGi advocate
Enterprise OSGi in Action (http://www.manning.com/cummins)
---


Date: Tue, 15 Nov 2011 14:34:23 -0600
Subject: Re: Strange OpenJPA and BP problem
From: mattmadha...@gmail.com
To: user@aries.apache.org

Hi Tim.Yes I ran to ARIES-765!
I do have my entities and presistence.xml in two different bundles.
After installing the persistence bundle and doing a reffresh in command line 
does seem to work!

Any fixes for ARIES-765 yet?
ThanksMatt

On Tue, Nov 15, 2011 at 1:05 PM, Matt Madhavan mattmadha...@gmail.com wrote:

Hi Tim,I'm running this in KARAF. Everything seems to deploy and all the 
bundles are active with all the services on.

Any idea please? Whats the work around for  ARIES-765 ?


Thanks in advance!


Matt

On Tue, Nov 15, 2011 at 3:04 AM, Timothy Ward timothyjw...@apache.org wrote:







Hi Matt, 

Without more context it is very difficult to debug remotely - did anything get 
redeployed? It looks like you've hit ARIES-765 to me.

Regards

Tim Ward
---
Apache Aries PMC member  Enterprise OSGi advocate


Enterprise OSGi in Action (http://www.manning.com/cummins)
---


Date: Mon, 14 Nov 2011 18:20:40 -0600
Subject: Strange OpenJPA and BP problem


From: mattmadha...@gmail.com
To: user@aries.apache.org

Hello,
I have configured an in-memory Derby data source with open jpa and Aries 
blueprint.
When ever I invoke a a query i'm getting the following InvalidState exception! 
Not getting much info at all! Any ideas please?



openjpa-2.1.0-r422266:1071316 nonfatal user error 
org.apache.openjpa.persistence.InvalidStateException: The factory has been 
closed.  The stack trace at which the factory was closed is held in the 
embedded exception.


at 
org.apache.openjpa.kernel.AbstractBrokerFactory.assertOpen(AbstractBrokerFactory.java:676)
at 
org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:192)


at 
org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java:156)
at 
org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:227)


at 
org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:60)
at 
org.apache.aries.jpa.container.impl.CountingEntityManagerFactory.createEntityManager(CountingEntityManagerFactory.java:70)


at 
org.apache.aries.jpa.container.context.transaction.impl.JTAEntityManager.getPersistenceContext(JTAEntityManager.java:92)
at 
org.apache.aries.jpa.container.context.transaction.impl.JTAEntityManager.createNamedQuery(JTAEntityManager.java:310)


at 
com.hcsc.ccsp.foundation.core.activeclaims.impl.ReferenceTablesDaoImpl.findAllClmProcExcepRef(ReferenceTablesDaoImpl.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)


at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)   
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)


at 
org.apache.aries.proxy.impl.ProxyHandler$1.invoke(ProxyHandler.java:50)
at org.apache.aries.blueprint.proxy.Collaborator.invoke(Collaborator.java:91)   
 at org.apache.aries.proxy.impl.ProxyHandler.invoke(ProxyHandler.java:78)


at 
com.hcsc.ccsp.foundation.core.activeclaims.impl.$ReferenceTablesDaoImpl30102981.findAllClmProcExcepRef(Unknown
 Source)at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)



...
Caused by: java.lang.IllegalStateExceptionat 
org.apache.openjpa.kernel.AbstractBrokerFactory.close(AbstractBrokerFactory.java:406)


at 
org.apache.openjpa.kernel.DelegatingBrokerFactory.close(DelegatingBrokerFactory.java:197)
at 
org.apache.openjpa.persistence.EntityManagerFactoryImpl.close(EntityManagerFactoryImpl.java:275)


at 
org.apache.aries.jpa.container.impl.CountingEntityManagerFactory.close(CountingEntityManagerFactory.java:60)
at 
org.apache.aries.jpa.container.impl.EntityManagerFactoryManager.destroyEntityManagerFactories(EntityManagerFactoryManager.java:328)


at 
org.apache.aries.jpa.container.impl.EntityManagerFactoryManager.bundleStateChange(EntityManagerFactoryManager.java:169)
at 
org.apache.aries.jpa.container.impl.PersistenceBundleManager.modifiedBundle(PersistenceBundleManager.java:283)


at 
org.osgi.util.tracker.BundleTracker

RE: Support for interceptors?

[Timothy Ward]

Hi,

It is possible to use Service Hooks to hide the original services and publish 
proxied ones that you want people to use, however I would regard this as a very 
risky approach. Firstly, it is difficult to write a Service Hook correctly 
without accidentally breaking the service registry, accidentally filtering the 
wrong events can make things go badly wrong. Secondly it creates a very 
unpleasant ordering requirement (which is a bad thing in OSGi). If your hook is 
registered after one of the services it should have been filtering then there 
may be bundles using it already. At this point hiding the service from those 
clients prevents them finding out when the service goes away.

There's quite a good blog post about Service Hooks here: 
http://www.osgi.org/blog/2009/02/osgi-service-hooks.html which explains why 
they aren't for the faint hearted. I would strongly recommend using blueprint 
instead, mostly because it's simpler to implement, but also because it won't 
break anything else if it goes wrong, and it will reliably work in any ordering 
scenario.

As for your worry about dynamism, interceptors are not a static model. You can 
change the behaviour of your interceptor every time it is called (if that's 
what you want). You could stop logging, starting transactions, counting 
invocations, or whatever you are doing with your aspect, at any time then start 
doing it again later if you want.

My personal recommendation would be to avoid service hooks for this sort of use 
case, particularly when Aries blueprint already offers you a proxied, 
intercepted service model.


Tim Ward
---
Apache Aries PMC member  Enterprise OSGi advocate
Enterprise OSGi in Action (http://www.manning.com/cummins)
---


Subject: RE: Support for interceptors?
Date: Mon, 14 Nov 2011 09:50:25 +0100
From: frederik.debac...@dexia.com
To: user@aries.apache.org










Hi all,
 
Thx for the response. I had started looking into the spec and was 
thinking to use the Service Hook specs to solve this. What is your opinion 
about 
using this approach? I guess the advantage could be that we can put the proxy 
implementation in a separate bundle and that we can deploy/activate 
this dynamically without having to change the 'to be proxied' 
service.
 
thx and kr,
 
Frederik.



From: timothyjw...@hotmail.com 
[mailto:timothyjw...@hotmail.com] On Behalf Of Timothy 
Ward
Sent: vrijdag 11 november 2011 16:33
To: 
user@aries.apache.org
Subject: RE: Support for 
interceptors?



Hi Frederik,

As Graham says, the way to implement this is 
with a namespace handler. If you create your own namespace then you can add an 
element (or attribute) in the service you want to be intercepted.

The 
namespace handler can then do something like this:

public Metadata 
parse(Element elt, ParserContext pc)

{
Metadata m = 
pc.getEnclosingComponent();


ComponentDefinitionRegistry cdr = 
pc.getComponentDefinitionRegistry();


Interceptor interceptor = 
getMyInterceptor();

if(cm 
instanceof 
ServiceMetadata)

cdr.registerInterceptorWithComponent(cm, 
interceptor);

else
throw 
new RuntimeException(Not a service 
component);

return 
null;
}

I hope this is helpful, it seems like 
you're using some pretty advanced blueprint, may I ask what it's for?

Tim 
Ward
---
Apache Aries PMC member  Enterprise OSGi 
advocate
Enterprise OSGi in Action (http://www.manning.com/cummins)
---



 Date: Fri, 11 Nov 2011 09:20:06 +
 Subject: Re: Support for 
interceptors?
 From: gchart...@gmail.com
 To: 
user@aries.apache.org
 
 Hi Frederik,
 
 The way to 
get interceptors involved in Blueprint is to add a
 namespace handler. 
This is something that processes a blueprint
 namespace extension. So you 
would define a namespace that you would
 add to blueprint, and maybe an 
associated element that you would
 include to identify the services to be 
intercepted, and then your
 namespace handler would be engaged and have 
the opportunity to do its
 work.
 
 Apache Aries has a 
number of examples of this (e.g. JPA,
 Transactions). I'd probably start 
by taking a look at the one for
 transactions: 
https://svn.apache.org/repos/asf/aries/trunk/transaction/transaction-blueprint/
 

 I hope this helps.
 
 Regards, Graham.
 
 
On 10 November 2011 06:48, De Backer Frederik (DBB)
 
frederik.debac...@dexia.com wrote:
  Hello all,
 

  I am wondering if the OSGi Enterprise specification has some 
support to
  define interceptors on OSGi service methods. Suppose for 
example that I want
  to log the request parameters of a method, is 
it possible to define an
  interceptor in the blueprint.xml method on 
the service definition. I guess
  not because I haven't found 
anything until now. Is there some recommended
  approach to implement 
this? For example, by using an AOP framework like
  aspectj or using 
spring annotations

RE: Support for interceptors?

[Timothy Ward]

Hi Frederik,

As Graham says, the way to implement this is with a namespace handler. If you 
create your own namespace then you can add an element (or attribute) in the 
service you want to be intercepted.

The namespace handler can then do something like this:

public Metadata parse(Element elt, ParserContext pc)
{
Metadata m = pc.getEnclosingComponent();

ComponentDefinitionRegistry cdr = pc.getComponentDefinitionRegistry();

Interceptor interceptor = getMyInterceptor();

if(cm instanceof ServiceMetadata)
cdr.registerInterceptorWithComponent(cm, interceptor);
else
throw new RuntimeException(Not a service component);

return null;
}

I hope this is helpful, it seems like you're using some pretty advanced 
blueprint, may I ask what it's for?

Tim Ward
---
Apache Aries PMC member  Enterprise OSGi advocate
Enterprise OSGi in Action (http://www.manning.com/cummins)
---


 Date: Fri, 11 Nov 2011 09:20:06 +
 Subject: Re: Support for interceptors?
 From: gchart...@gmail.com
 To: user@aries.apache.org
 
 Hi Frederik,
 
 The way to get interceptors involved in Blueprint is to add a
 namespace handler.  This is something that processes a blueprint
 namespace extension.  So you would define a namespace that you would
 add to blueprint, and maybe an associated element that you would
 include to identify the services to be intercepted, and then your
 namespace handler would be engaged and have the opportunity to do its
 work.
 
 Apache Aries has a number of examples of this (e.g. JPA,
 Transactions).  I'd probably start by taking a look at the one for
 transactions: 
 https://svn.apache.org/repos/asf/aries/trunk/transaction/transaction-blueprint/
 
 I hope this helps.
 
 Regards, Graham.
 
 On 10 November 2011 06:48, De Backer Frederik (DBB)
 frederik.debac...@dexia.com wrote:
  Hello all,
 
  I am wondering if the OSGi Enterprise specification has some support to
  define interceptors on OSGi service methods. Suppose for example that I want
  to log the request parameters of a method, is it possible to define an
  interceptor in the blueprint.xml method on the service definition. I guess
  not because I haven't found anything until now. Is there some recommended
  approach to implement this? For example, by using an AOP framework like
  aspectj or using spring annotations (however in the last case I don't how
  how it is possible to define the annotations since I would need another
  spring-beans.xml file to define my annotations, next to my blueprint.xml
  file). Has someone done any work on this?
 
  Thx a lot for the assistance and kind regards,
 
  Frederik.
 
  -
  Dexia disclaimer:
 
  http://www.dexia.com/maildisclaimer.htm
  -
 
 
  

RE: Exposing Services Remotely

[Timothy Ward]

I have used DOSGi successfully with Aries, and there will be a discussion of 
using in Enterprise OSGi in Action (http://www.manning.com/cummins)

DOSGi is really good for exposing OSGi services as Web Services, and for 
consuming Web Services as OSGi services. I would definitely recommend it. The 
only thing I would say against it is that I have only been successful using the 
single bundle distribution of DOSGi 1.2, and that it can have one or two funny 
interactions with the Jetty web container if you have it installed.

I have also been working on Modular EJB support in Aries, and we have a 
working integration with OpenEJB currently sitting in trunk (we won't be 
releasing until OpenEJB 4.0.0 is released, and we have some doc). This works 
nicely with the Remote Services specification (DOSGi) and also with the more 
normal remote EJB model.

Regards,

Tim

To: user@aries.apache.org; user@aries.apache.org
From: j...@nanthrax.net
Subject: Re: Exposing Services Remotely
Date: Thu, 27 Oct 2011 23:00:06 +0200

Sorry I forgot to mention Fabric.

Regards
JB

--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://wwx.talend.com

- Reply message -
From: Guillaume Nodet gno...@gmail.com
To: user@aries.apache.org
Subject: Exposing Services Remotely
Date: Thu, Oct 27, 2011 8:08 pm


DOSGi is good if you want remoting between OSGi frameworks (that use the same 
DOSGi providers mainly).Else, maybe JAXWS is the easiest way to go.
If you're looking at a very fast DOSGi implementation, you could have a look at 
my blog (http://gnodet.blogspot.com/2011/06/distributed-osgi-in-fabric.html).


On Thu, Oct 27, 2011 at 17:20, De Backer Frederik (DBB) 
frederik.debac...@dexia.com wrote:











Hello,


I have been playing around with Aries over the last few days and I have been 
able to make some services via blueprint framework. However, now I would like 
to expose these services remotely (EJB-like via RMI or WS-style via SOAP). What 
is the recommended approach to do this? Is there already some support in the 
current version of Aries to do this or is this planned in the future? Should I 
use an app server like Geronimo and deploy my bundles in there after which I 
can use the typical JEE services (such as remoting) provided by an app server. 
Or should I go for a framework like the DOSGi framework of CXF?


Any pointers regarding the possibilities, recommended approaches, experiences, 
samples would be very much appreciated.


Thx for the help,


Frederik.




pre

-
Dexia disclaimer:

http://www.dexia.com/maildisclaimer.htm
-
/pre



-- 

Guillaume Nodet

Blog: http://gnodet.blogspot.com/


Open Source SOA
http://fusesource.com


  

RE: Meaning of this message

[Timothy Ward]

Hi,

This probably means that you are shutting down your JPA runtime and there is no 
longer any managed persistence support (i.e. you have stopped the aries JPA 
container context bundle). That's the only time this message is issued.

Regards,

Tim


 Date: Mon, 24 Oct 2011 20:17:41 +0200
 Subject: Meaning of this message
 From: cmoulli...@gmail.com
 To: user@aries.apache.org
 
 Hi,
 
 When deploying a aries-jpa bundle, I get this message in the log :
 
 20:03:05,229 | WARN  | rint Extender: 1 | aries
  | ?   ? | 189 -
 org.apache.aries.jpa.blueprint.aries - 0.3.0 | Managed persistence
 context support is no longer available for use with the Aries
 Blueprint container
 
 How should I interpretate that and what should I do in the
 config/parametrisation of Apache Aries JPA ?
 
 Regards,
 
 Charles Moulliard
 
 Apache Committer
 
 Blog : http://cmoulliard.blogspot.com
 Twitter : http://twitter.com/cmoulliard
 Linkedin : http://www.linkedin.com/in/charlesmoulliard
 Skype: cmoulliard
  

RE: Service property assigned with a service reference

[Timothy Ward]

I think that what you're doing should work fine (assuming the service is 
actually of type String) and this indcates a blueprint bug. If your service is 
actually not a String then if you add a type of java.lang.String (to tell 
blueprint to toString your object) things should probably work ok. The property 
will only be set once though, regardless of whether the reference changes, (no 
dynamism) because of what the spec says.

Regards,

Tim

Date: Tue, 25 Oct 2011 10:26:46 +0200
From: david.fel...@scalagent.com
To: user@aries.apache.org
Subject: Re: Service property assigned with a service reference


  



  
  
My object is a String (a URI) that needs to be dynamically resolved
as a reference (reference) and passed as a service property.



So if I correctly understood what you said, there's no way to do
that with blueprint?

It worked with Aries but it's only by chance, isn't it?



Thanks again,

Regards,

David



Le 24/10/2011 15:55, Timothy Ward a écrit :

  
  
Hi,



It is allowed to use a component instance as a service property,
however the following rules apply (from 121.6.6 of the
enterprise specification)



Each service can optionally be registered with service
properties. The serviceProperties is a list of

MapEntry, see entry on page 236. This metadata must be
used to create the service properties. Service

properties creation can have side effects because they can use
component instances. The service

properties must therefore be created once before the first time
the first time the service is registered.







Service properties should specify the valueType of the entry
unless the value to be registered needs to

be a String object. The service property types should be one of:

• Primitives Number – int, long, float, double, byte, short,
char, boolean

• Scalar – String, Integer, Long, Float, Double, Byte, Short,
Character, Boolean.

• Array – An array of either the allowable primitive or scalar
types.

• Collection – An object implementing the Collection interface
that contains scalar types.





If your object is of any other type then it should be being
turned into a String, which does indicate an issue with the
blueprint container. On the other hand, it may not be possible
to do what you actually want to do.



Aries blueprint will probably cope with some other property
types as well (things that have a String constructor), but I
couldn't give you a complete list.



Regards,



Tim





 Date: Mon, 24 Oct 2011 10:14:03 +0200

   From: david.fel...@scalagent.com

   To: user@aries.apache.org

   Subject: Service property assigned with a service
  reference

   

   Hi,

   

   when defining a service property with a reference as a
  value, the 

   property is assigned with a ServiceProxyWrapper (inner
  class of 

   ReferenceRecipe).

   

   Here is the way it is defined:

   

   service ref=... interface=...

   service-properties

   entry key=Property1

   ref component-id=serviceRef/

   /entry

   /service-properties

   /service

   

   reference id=serviceRef interface=A /

   

   I would have expected the service property Property1 to
  be assigned 

   with an instance of A instead of a ServiceProxyWrapper.
  However I 

   could get the instance of A by calling the method
  'convert' and 

   passing a ReifiedType.

   

   I would like to know if defining such a service property
  (containing a 

   ref) is correct according to Blueprint
  specification and Aries 

   implementation?

   

   I would also like to know why the 'convert' has to be
  done explicitly?

   

   Thank you.

   Regards,

   David

   

   

   


  


  

RE: Service property assigned with a service reference

[Timothy Ward]

I apologise for the confusion, I was under the impression that the service 
properties element extended the map element, but apparently it doesn't. As such 
it won't let you specify a value-type...

I suggest you raise a bug for the problem you're seeing. Whatever happens you 
shouldn't end up with an internal blueprint recipe object in there.

Tim

Date: Tue, 25 Oct 2011 14:40:54 +0200
From: david.fel...@scalagent.com
To: user@aries.apache.org
Subject: Re: Service property assigned with a service reference


  



  
  
If the service is a String, then an exception is raised because the
String class is final:



org.apache.aries.proxy.FinalModifierException: The class
java.lang.String is final.

at
org.apache.aries.blueprint.container.ReferenceRecipe.internalCreate(ReferenceRecipe.java:98)

...



If the service is not a String, then I don't see how I can add a
type of java.lang.String because such a type indication is only
available with value and not ref.



service-properties

  entry key=Property1

ref component-id=serviceRef/

  /entry

/service-properties



Regards,

David



Le 25/10/2011 13:19, Timothy Ward a écrit :

  
  
I think that what you're doing should work fine (assuming the
service is actually of type String) and this indcates a
blueprint bug. If your service is actually not a String then if
you add a type of java.lang.String (to tell blueprint to
toString your object) things should probably work ok. The
property will only be set once though, regardless of whether the
reference changes, (no dynamism) because of what the spec says.



Regards,



Tim




  Date: Tue, 25 Oct 2011 10:26:46 +0200

  From: david.fel...@scalagent.com

  To: user@aries.apache.org

  Subject: Re: Service property assigned with a service
  reference

  

  
  
  My object is a String (a URI) that needs to be dynamically
  resolved as a reference (reference) and passed as a
  service property.

  

  So if I correctly understood what you said, there's no way to
  do that with blueprint?

  It worked with Aries but it's only by chance, isn't it?

  

  Thanks again,

  Regards,

  David

  

  Le 24/10/2011 15:55, Timothy Ward a écrit :
  

 Hi,

  

  It is allowed to use a component instance as a service
  property, however the following rules apply (from 121.6.6
  of the enterprise specification)

  

  Each service can optionally be registered with service
  properties. The serviceProperties is a list of

  MapEntry, see entry on page 236. This metadata
  must be used to create the service properties. Service

  properties creation can have side effects because they can
  use component instances. The service

  properties must therefore be created once before the first
  time the first time the service is registered.

  

  

  

  Service properties should specify the valueType of the
  entry unless the value to be registered needs to

  be a String object. The service property types should be
  one of:

  • Primitives Number – int, long, float, double, byte,
  short, char, boolean

  • Scalar – String, Integer, Long, Float, Double, Byte,
  Short, Character, Boolean.

  • Array – An array of either the allowable primitive or
  scalar types.

  • Collection – An object implementing the Collection
  interface that contains scalar types.

  

  

  If your object is of any other type then it should be
  being turned into a String, which does indicate an issue
  with the blueprint container. On the other hand, it may
  not be possible to do what you actually want to do.

  

  Aries blueprint will probably cope with some other
  property types as well (things that have a String
  constructor), but I couldn't give you a complete list.

  

  Regards,

  

  Tim

  

  

   Date: Mon, 24 Oct 2011 10:14:03 +0200

 From: david.fel...@scalagent.com

 To: user@aries.apache.org

 Subject: Service property assigned with a service
reference

 

 Hi

RE: Service property assigned with a service reference

[Timothy Ward]

Hi,

It is allowed to use a component instance as a service property, however the 
following rules apply (from 121.6.6 of the enterprise specification)

Each service can optionally be registered with service properties. The 
serviceProperties is a list of
MapEntry, see entry on page 236. This metadata must be used to create the 
service properties. Service
properties creation can have side effects because they can use component 
instances. The service
properties must therefore be created once before the first time the first time 
the service is registered.



Service properties should specify the valueType of the entry unless the value 
to be registered needs to
be a String object. The service property types should be one of:
• Primitives Number – int, long, float, double, byte, short, char, boolean
• Scalar – String, Integer, Long, Float, Double, Byte, Short, Character, 
Boolean.
• Array – An array of either the allowable primitive or scalar types.
• Collection – An object implementing the Collection interface that contains 
scalar types.


If your object is of any other type then it should be being turned into a 
String, which does indicate an issue with the blueprint container. On the other 
hand, it may not be possible to do what you actually want to do.

Aries blueprint will probably cope with some other property types as well 
(things that have a String constructor), but I couldn't give you a complete 
list.

Regards,

Tim


 Date: Mon, 24 Oct 2011 10:14:03 +0200
 From: david.fel...@scalagent.com
 To: user@aries.apache.org
 Subject: Service property assigned with a service reference
 
 Hi,
 
 when defining a service property with a reference as a value, the 
 property is assigned with a ServiceProxyWrapper (inner class of 
 ReferenceRecipe).
 
 Here is the way it is defined:
 
 service ref=... interface=...
 service-properties
 entry key=Property1
 ref component-id=serviceRef/
 /entry
 /service-properties
 /service
 
 reference id=serviceRef interface=A /
 
 I would have expected the service property Property1 to be assigned 
 with an instance of A instead of a ServiceProxyWrapper. However I 
 could get the instance of A by calling the method 'convert' and 
 passing a ReifiedType.
 
 I would like to know if defining such a service property (containing a 
 ref) is correct according to Blueprint specification and Aries 
 implementation?
 
 I would also like to know why the 'convert' has to be done explicitly?
 
 Thank you.
 Regards,
 David
 
 
 
  

RE: Generics And Aries Blueprint

[Timothy Ward]

Hi,

I would expect this to work, have you tried specifying index parameters for the 
constructor arguments?

Also, it would be worth opening a JIRA with some failing example code attached 
(unless of course you want to supply some tests and a fix :)). Blueprint gets 
fairly regular attention from the committers, so I imagine a JIRA will get 
dealt with reasonably quickly.

Regards,

Tim

 Date: Mon, 10 Oct 2011 12:54:42 -0400
 Subject: Generics And Aries Blueprint
 From: gareth.o.coll...@gmail.com
 To: user@aries.apache.org
 
 Hello,
 
 Is injection using java 5 generics allowed?
 
 My scenario - I am creating two generic classes:
 
 public class MyClass1V extends MyBaseClass implements Runnable {
 public MyClass1(long myArgument) {
 }
 }
 
 -
 public class MyClass2E extends MyBaseClass implements MyInterfaceE {
 // just using default constructor
 }
 
 which I want to insert into another class:
 
 public class MyClass3 {
   public MyClass3(MyClass1MyImplementationClass myClass1,
 MyInterfaceMyImplementationClass myInterface) {
 }
 }
 
 In my blueprint file I have:
 
   bean id=myClass1 class=com.mycompany.MyClass1
 init-method=start destroy-method=stop
   argument value=5000 /
   /bean
   
   bean id=myClass2 class=com.mycompany.MyClass2 /
   
   bean id=myClass3 class=com.mycompany.MyClass3 
   argument ref=myClass1/
   argument ref=myClass2/
   /bean
 
 If I run this as is, blueprint will throw the following exception:
 
 org.osgi.service.blueprint.container.ComponentDefinitionException:
 Unable to find a matching constructor on class com.myCompany.myClass3
 for arguments [com.mycompany.MyClass1@787f7957,
 com.mycompany.MyClass2@66525531] when instanciating bean myClass3
 at 
 org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:272)[31:org.apache.aries.blueprint:0.3.1]
 at 
 org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:706)[31:org.apache.aries.blueprint:0.3.1]
 at 
 org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64)[31:org.apache.aries.blueprint:0.3.1]
 at 
 org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:219)[31:org.apache.aries.blueprint:0.3.1]
 at 
 org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:147)[31:org.apache.aries.blueprint:0.3.1]
 at 
 org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:640)[31:org.apache.aries.blueprint:0.3.1]
 at 
 org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:331)[31:org.apache.aries.blueprint:0.3.1]
 at 
 org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:227)[31:org.apache.aries.blueprint:0.3.1]
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_26]
 at 
 java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_26]
 at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_26]
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_26]
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)[:1.6.0_26]
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_26]
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_26]
 at java.lang.Thread.run(Thread.java:680)[:1.6.0_26]
 
 If I remove the generic specification from the MyClass3 constructor,
 everything works OK:
 
 public class MyClass3 {
   public MyClass3(MyClass1 myClass1, MyInterface myInterface) {
 }
 }
 
 Is that what is supposed to happen? Am I not allowed to use generics
 in constructor arguments?
 
 thanks in advance,
 Gareth
  

RE: Aries Blueprint 0.4?

[Timothy Ward]

Hi Gareth

We are working toward a release of blueprint right now. Unfortunately getting 
ready for this release has flagged some historical errors in the versioning 
policy of our pom files, so we're also having to release a number of of other 
projects with fixes for this. We hope to have a blueprint release in the next 
few weeks.

Tim

 Date: Sun, 9 Oct 2011 23:56:30 -0400
 Subject: Aries Blueprint 0.4?
 From: gareth.o.coll...@gmail.com
 To: user@aries.apache.org
 
 Hello,
 
 I am curious - is a release of Aries Blueprint 0.4 planned soon?
 
 I ask this as I have found some quirks with the current version
 (0.3.1), but I know that
 a lot of changes have been made since this release (from March?).
 
 If a release of blueprint is not planned for the near future, is the
 best idea (for now) to
 work off aries trunk?
 
 thanks in advance,
 Gareth
  

RE: KARAF and JPA Bundle issues - Urgent

[Timothy Ward]

Hi,

Are you still seeing this problem? Have you tried debugging to see why your 
Persistence Provider service might be null?

Regards,

Tim

Date: Fri, 16 Sep 2011 18:17:33 -0500
Subject: KARAF and JPA Bundle issues - Urgent
From: mattmadha...@gmail.com
To: user@aries.apache.org; us...@felix.apache.org; anpie...@gmail.com; 
n...@apache.org

Hello,I moving couple of my sample applications from pax:provision to Apache 
Karaf. Both application run ok on pax:provision inside of a Felix container.
But when I run the same applications (derby/openjpa 2.0, aries) I'm getting a 
null pointer exception when I start my persistence bundle. The same bundle 
worked fine in pax:provision!

Can some one send me an example or send me the list of Bundles/Features I must 
have in order to make this work?
I would greatly appreciate it.
The errors are as follows:
The log says:2011-09-16 17:57:07,578 | INFO  | rint Extender: 2 | 
BlueprintContainerImpl   | container.BlueprintContainerImpl  305 | 9 - 
org.apache.aries.blueprint - 0.3.1 | Bundle itso.bank.persistence is waiting 
for dependencies 
[(((org.apache.aries.jpa.proxy.factory=true)(osgi.unit.name=itso.bank.persistence))(objectClass=javax.persistence.EntityManagerFactory))]
2011-09-16 18:02:07,578 | ERROR | rint Extender: 3 | BlueprintContainerImpl 
  | ntainer.BlueprintContainerImpl$1  293 | 9 - org.apache.aries.blueprint 
- 0.3.1 | Unable to start blueprint container for bundle itso.bank.persistence 
due to unresolved dependencies 
[(((org.apache.aries.jpa.proxy.factory=true)(osgi.unit.name=itso.bank.persistence))(objectClass=javax.persistence.EntityManagerFactory))]
java.util.concurrent.TimeoutException   at 
org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:287)[9:org.apache.aries.blueprint:0.3.1]


But the console output says:
karaf@root start 207ERROR: Bundle org.apache.aries.jpa.container [126] 
EventDispatcher: Error during dispatch. (java.lang.NullPointerExcepti
on)java.lang.NullPointerExceptionat 
org.apache.aries.jpa.container.impl.PersistenceBundleManager$ProviderServiceComparator.compare(PersistenceBundleManager.java:575)
at 
org.apache.aries.jpa.container.impl.PersistenceBundleManager$ProviderServiceComparator.compare(PersistenceBundleManager.java:572)
at java.util.Collections.max(Collections.java:681)
at 
org.apache.aries.jpa.container.impl.PersistenceBundleManager.getBestProvider(PersistenceBundleManager.java:554)
at 
org.apache.aries.jpa.container.impl.PersistenceBundleManager.getProviderServiceReference(PersistenceBundleMan
ager.java:460)
Any help will be appreciated.
ThanksMatt
  

RE: OSGi (Blueprint) fragment and host bundle notification

[Timothy Ward]

Hi,

From the original question I would say No, there is no way for a host bundle 
to receive a notification when a fragment attaches. Fragments only attach at 
resolution time, therefore the host bundle can never see the attachment 
because it is, by definition, not resolved yet!

What you can do is the following at startup (On OSGi 4.3):

  public void start(BundleContext ctx) throws BundleException {

Bundle hostBundle = ctx.getBundle();

BundleWiring wiring = hostBundle.adapt(BundleWiring.class);

CollectionBundleWire fragmentWires = wiring.
   getProvidedWires(BundleRevision.HOST_NAMESPACE);

for(BundleWire wire : fragmentWires) {
  Bundle fragment = wire.getRequirerWiring().getBundle();
  //Do some stuff with this fragment
}
  }

This will allow you to find out which fragments were wired to your bundle when 
it resolved.

Regards,

Tim

From: mnutt...@apache.org
Date: Wed, 7 Sep 2011 08:54:57 +0100
Subject: Re: OSGi (Blueprint) fragment and host bundle notification
To: user@aries.apache.org

Hi Matt, A web search for osgi bundle tracker fragment yields this article: 
http://java.dzone.com/articles/osgi-junit-test-extender-using. This uses a 
BundleTrackerCustomizer, 




bundleTracker = new BundleTracker(context, Bundle.RESOLVED, testExtender);

bundleTracker.open();


Which then tests to see if it's been given a fragment:
String fragment = 
bundle.getHeaders().get(org.osgi.framework.Constants.FRAGMENT_HOST) + ;


 Thanks in advance!
You're welcome!
Regards, Mark

On 6 September 2011 23:14, Matt Madhavan mattmadha...@gmail.com wrote:


Hello,I would like to know when a new BluePrint fragment attaches it self to a 
host bundle will the host bundle be notified? I would like to do some work 
inside of the host bundle anytime a fragment attaches itself to a host.



Any ideas?
Thanks in advance!Matt Madhavan

  

RE: Auditor and OSGi

[Timothy Ward]

Hi,

So the Aries JPA container uses the createContainerEntityManagerFactory method 
to build EMFs. This provides, amongst other things, a ClassLoader for the 
persistence unit. IMO JPA providers should use this to load config if it isn't 
found on their own classloader.

Regards,

Tim

Date: Tue, 6 Sep 2011 21:47:19 +0200
Subject: Re: Auditor and OSGi
From: be...@rodehav.com
To: user@aries.apache.org

Thanks for your reply Tim,
I agree, it seems like OpenJPA uses its own classloader to load my auditor 
implementation. That won't work of course. Is best practice for JPA providers 
to use the class loader for the bundle containing  the persistence.xml?

/Bengt

2011/9/6 Timothy Ward timothyjw...@apache.org






This sort of problem is usually caused by a JPA provider using the wrong 
classloader to try and find your class. If you import the 
se.digia.maia.common.auditlog.impl package into your persistence bundle *and* 
OpenJPA uses the Persistence Unit classloader (rather than its own) to load it 
then everything should work fine. Realistically they should try both their 
classloader and the persistence unit classloader in case the config property is 
for their own internals.


Unfortunately there is a limit to how much Aries can shield JPA providers from 
OSGi classloading!

Regards,

Tim



Date: Mon, 5 Sep 2011 23:01:07 +0200
Subject: Auditor and OSGi

From: be...@rodehav.com
To: user@aries.apache.org

I posted the following mail on OpenJPA's mailing list but got no answer. I'm 
posting it on the Aries mailing list as well since I suspect that this may 
rather depend on the JPA container in Aries than on OpenJPA itself.




/Bengt


Hello everyone,






After a long discussion about audit logging on this mailing list, Pinaki 
developed an audit logging facility that he describes on:






http://openjpa.208410.n2.nabble.com/OpenJPA-Audit-Facility-tc6722915.html






It provides very interesting functionality and I've tried it in simple JUnit 
scenarios using RESOURCE_LOCAL and it seems to work fine. However, my 
production environment nowadays is OSGi using Karaf+Felix. I use Aries for 
transaction support and also for it's JPA support. In that environment, OpenJPA 
doesn't seem to be able to find my auditor implementation 
(se.digia.maia.common.auditlog.impl.MaiaAuditor) that I specify in my 
persistence.xml.






Has anyone else tried OpenJPA's new audit log facility? How can I make OpenJPA 
find classes specified in the persistence.xml? I have double-checked that the 
se.digia.maia.common.auditlog.impl is exported from my implementing bundle.












I get the following exception:







ERROR: Bundle org.apache.aries.jpa.container [21] EventDispatcher: Error during 
dispatch. (openjpa-2.2.0-SNAPSHOT-runknown fatal user error 
org.apache.openjpa.persistence.ArgumentException: Could not invoke the static 
newInstance method on the named factory class 
org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.)






openjpa-2.2.0-SNAPSHOT-runknown fatal user error 
org.apache.openjpa.persistence.ArgumentException: Could not invoke the static 
newInstance method on the named factory class 
org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.






at 
org.apache.openjpa.kernel.Bootstrap.newBrokerFactory(Bootstrap.java:76)
at 
org.apache.openjpa.persistence.PersistenceProviderImpl.getBrokerFactory(PersistenceProviderImpl.java:147)






at 
org.apache.openjpa.persistence.PersistenceProviderImpl.createContainerEntityManagerFactory(PersistenceProviderImpl.java:185)
at 
org.apache.openjpa.persistence.PersistenceProviderImpl.createContainerEntityManagerFactory(PersistenceProviderImpl.java:62)






at 
org.apache.aries.jpa.container.impl.EntityManagerFactoryManager.createEntityManagerFactories(EntityManagerFactoryManager.java:263)
at 
org.apache.aries.jpa.container.impl.EntityManagerFactoryManager.bundleStateChange(EntityManagerFactoryManager.java:153)






at 
org.apache.aries.jpa.container.impl.PersistenceBundleManager.modifiedBundle(PersistenceBundleManager.java:283)
at 
org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:453)






at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:237)
at 
org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:413)






at 
org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:807)
at 
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:729)






at 
org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:610)
at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:3879)






at org.apache.felix.framework.Felix.access$800(Felix.java:79)
at 
org.apache.felix.framework.Felix$StatefulResolver.fireResolvedEvents(Felix.java:4491

RE: Problem with Aries JPA

[Timothy Ward]

Hi,

The error stack you are showing indicates that the blueprint for the blog 
persistence bundle failed to start because there was no EntityManagerFactory 
service. This could be the case for a number of reasons, for example missing 
DataSources, Databases, missing JPA container bundles etc.

Are there other errors higher up the log?

Regards,

Tim

 Date: Mon, 5 Sep 2011 13:48:42 +0100
 Subject: Problem with Aries JPA
 From: r.o...@nature.com
 To: user@aries.apache.org
 
 Hi,
 
 I've run into difficulties while trying to launch Aries blog JPA example
 (0.2-incubating version) on Apache Service Mix 4.3. The exception I get is
 the following:
 
 karaf@root [Blueprint Extender: 3] ERROR
 org.apache.aries.blueprint.container.BlueprintContainerImpl - Unable to
 start blueprint container for bundle
 org.apache.aries.samples.blog.persistence.jpa due to unresolved dependencies
 [(((org.apache.aries.jpa.proxy.factory=*)(osgi.unit.name=blogExample))(obj
 ectClass=javax.persistence.EntityManagerFactory))]
 java.util.concurrent.TimeoutException
 at 
 org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintC
 ontainerImpl.java:273)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 at java.util.concurrent.FutureTask.run(FutureTask.java:138)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$
 301(ScheduledThreadPoolExecutor.java:98)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Sch
 eduledThreadPoolExecutor.java:206)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.ja
 va:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:9
 08)
 at java.lang.Thread.run(Thread.java:680)
 
 
 
 My setup as far as I know is pretty much standard: I've just installed Aries
 0.2-incubating distribution plus couple of dependencies.
 
 What am I missing ?
 
 I am using openjpa in version 2.0.1 as my persistence provider.
 
 On 02/09/2011 16:45, Johan Edstrom seij...@gmail.com wrote:
 
  They are probably at a lower start level, thus not visible.
  you have aries 0.2 if you look into startup.properties, otherwise Aries TX
  would not be able to start.
  
  
  On Sep 2, 2011, at 9:02 AM, Ozga, Rafal wrote:
  
  Hi, 
  
  Hm, I have installed Apache Service Mix 4.3 and all I can see is:
  
  karaf@root list | grep Aries
  [  49] [Active ] [] [   ] [   60] Apache Aries
  Transaction Manager (0.2.0.incubating)
  
  karaf@root features:list | grep Aries
  karaf@root
  
  which is far from being a complete Aries distribution.
  
  What am I missing then ?
  
  
  On 31/08/2011 17:34, Johan Edstrom seij...@gmail.com wrote:
  
  Servicemix already contains Aries
  
  
  On Aug 31, 2011, at 9:20, Ozga, Rafal r.o...@nature.com wrote:
  
  Hi,
  
  I¹d like to install Apache Aries in version 0.2-incubating or 0.3 on 
  Apache
  Service Mix.  Could you please tell me what are the dependencies Aries
  requires ? It would be nice if you let me know where to find or how to
  quickly create a feature.xml that would contain all those dependencies.
  
  Kind regards,
  
  Rafal Ozga, Software Developer
  Nature Publishing Group
  ***
  *   
  DISCLAIMER: This e-mail is confidential and should not be used by anyone
  who is
  not the original intended recipient. If you have received this e-mail in
  error
  please inform the sender and delete it from your mailbox or any other
  storage
  mechanism. Neither Macmillan Publishers Limited nor any of its agents
  accept
  liability for any statements made which are clearly the sender's own and
  not
  expressly made on behalf of Macmillan Publishers Limited or one of its
  agents.
  Please note that neither Macmillan Publishers Limited nor any of its 
  agents
  accept any responsibility for viruses that may be contained in this 
  e-mail
  or
  its attachments and it is your responsibility to scan the e-mail and
  attachments (if any). No contracts may be concluded on behalf of 
  Macmillan
  Publishers Limited or its agents by means of e-mail communication.
  Macmillan 
  Publishers Limited Registered in England and Wales with registered number
  785998 
  Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
  ***
  * 
  
  
 
 
 

 DISCLAIMER: This e-mail is confidential and should not be used by anyone who 
 is
 not the original intended recipient. If you have received this e-mail in error
 please inform the sender and delete it from your mailbox or any other storage
 mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
 liability for any 

RE: Persisted record are not visible from 'outside'

[Timothy Ward]

Hi,

From the logs things seem to be operating properly, but I do have two 
questions.

Is the transaction where the data is written actually committing before the 
transaction that reads it? I don't see any log for Clearing up EntityManager 
 as the transaction has completed.. If not then the data will not be 
visible in the next transactionIs the datasource being used integrating with 
the ongoing JTA transaction? If the datasource is not participating in the 
active transaction then it will never be committed to the database.
I'm sorry I can't give you a solution, but hopefully these questions will be 
helpful in determining the real problem.

Regards,

Tim

Date: Thu, 30 Jun 2011 10:31:49 +
Subject: Persisted record are not visible from 'outside'
From: younes.ou...@gmail.com
To: user@aries.apache.org

Dear All,
I'm seeking your help to address an issue within a ported application.
Actually, we have a Web application based on Spring Framework that we are 
working foreward to OSGi-fying it. I have finished the adaptations for a first 
part of the application and start testing it using:
* Aries as an OSGi EE specifications provider (JPA, Transaction and JNDI) 
version 0.3.0,* OpenJPA 2.0.1,* Karaf 2.2.1* and MySQL 5.1.
I'm able to persist data but unable to retrieve what I have persisted either 
from within the application itself or using MySQL tools.

I have activated DEBUG and I'm able to see clearly that persistence is handled 
fine (see part one of the log below). Also, I'm able to see clearly that the 
query is submitted properly but returning 0 record (see part 2 of the log 
below). Can someone help to direct me where I can look to fix this issue?

Compared to the directives for a 'JPA Bundle' described in Aries Documentation 
(here), our implementation is as follows:
* Separate bundles for JPA Entities (based on the architecture of our modules) 
with build-time enhancement* One dedicated bundle for the entity manager 
containing the 'persistence-unit' descriptor (listing all entities of the 
application) and the 'Meta-Persistence' OSGi header


Thank you in advance for your valuable help.

Younes Ouadi

Log part 1: persisting data (Here, I'm saving an object of type 
'com.natisco.persistence.integration.entities.Config')
09:32:58,701 | DEBUG | atisoft/jsondisp | JsonSaveConfigService| 
ices.commons.api.ServiceTemplate   92 | 137 - com.natisco.services.commons.api 
- 0.1.0.SNAPSHOT | Request 
[{name:saveConfig,configGroupOid:4451,configGroupCode:INTGR_SCHEME_UNITS,config:{comps:[],links:[],name:Config
 1,code:CFG1,descr:}}]
09:32:58,703 | DEBUG | atisoft/jsondisp | TxComponentMetaDataHelperImpl| 
on.TxComponentMetaDataHelperImpl  188 | 106 - 
org.apache.aries.transaction.blueprint - 0.3.0 | Getting the txAttribute for 
the component {0} and method {1}
09:32:58,704 | DEBUG | atisoft/jsondisp | TxComponentMetaDataHelperImpl| 
on.TxComponentMetaDataHelperImpl  200 | 106 - 
org.apache.aries.transaction.blueprint - 0.3.0 | Return the txAttribute {0} for 
the component and method
09:32:58,704 | DEBUG | atisoft/jsondisp | TxInterceptorImpl| 
es.transaction.TxInterceptorImpl  112 | 106 - 
org.apache.aries.transaction.blueprint - 0.3.0 | Method: public 
java.lang.Object 
com.natisco.persistence.kernel.commons.api.AbstractDao.findSingleIfAny(java.lang.Class,java.lang.String),
 has transaction strategy: REQUIRED
09:32:58,705 | DEBUG | atisoft/jsondisp | TxComponentMetaDataHelperImpl| 
on.TxComponentMetaDataHelperImpl  188 | 106 - 
org.apache.aries.transaction.blueprint - 0.3.0 | Getting the txAttribute for 
the component {0} and method {1}
09:32:58,705 | DEBUG | atisoft/jsondisp | TxComponentMetaDataHelperImpl| 
on.TxComponentMetaDataHelperImpl  200 | 106 - 
org.apache.aries.transaction.blueprint - 0.3.0 | Return the txAttribute {0} for 
the component and method
09:32:58,706 | DEBUG | atisoft/jsondisp | TxInterceptorImpl| 
es.transaction.TxInterceptorImpl  112 | 106 - 
org.apache.aries.transaction.blueprint - 0.3.0 | Method: public 
java.util.Collection 
com.natisco.persistence.kernel.commons.jpa.JpaDaoDriver.find(java.lang.String,java.lang.String[],java.lang.Object[],java.lang.Integer,java.lang.Integer),
 has transaction strategy: REQUIRED
09:32:58,707 | DEBUG | atisoft/jsondisp | context  | 
pl.JTAPersistenceContextRegistry  133 | 113 - 
org.apache.aries.jpa.container.context - 0.3.0 | Created a new persistence 
context org.apache.aries.jpa.container.impl.EntityManagerWrapper@3d0d64 for 
transaction 
[Xid:globalId=17000696e697469616c0,length=64,branchId=,length=64].
09:32:58,715 | DEBUG | atisoft/jsondisp | TxComponentMetaDataHelperImpl| 
on.TxComponentMetaDataHelperImpl  188 | 106 - 
org.apache.aries.transaction.blueprint - 0.3.0 | Getting the txAttribute for 
the component {0} and method {1}

RE: 0.4

[Timothy Ward]

Hi,

I'm happy to look at getting a new release of the Aries JPA container. There 
are a couple of hoops to jump through with the build, but now that Equinox 3.7 
and the OSGi 4.3 API are available it should be possible for us to get the 
build into a release-able state

Regards,

Tim

Date: Tue, 28 Jun 2011 09:18:51 +
Subject: Re: 0.4
From: younes.ou...@gmail.com
To: user@aries.apache.org

Hello Alasdair,
I endorse the point of view of both Bengt and Harald. It will be very 
interesting to release the enhancement allowing the runtime enhancer. This 
feature is more 'compatible' with the loose-coupling best-practice. Why should 
my 'entities bundles' know about their JPA Provider?

I believe that the big work has been already completed by implementing 
successfully the run-time enhancer. There is just a small but important step 
that remains: officially offer that important feature to the public.

Warm regards.

Younes Ouadi


On Tue, Jun 28, 2011 at 8:04 AM, Bengt Rodehav be...@rodehav.com wrote:

Thanks for your reply Alasdair,
Reading the documentation about the JPA support it seems like in 0.4, it is no 
longer necessary to list all classes in the persistence.xml. That's an 
improvement I'm really interested in which is why asked about the 0.4 release. 
I also use Karaf+Camel and I'm used to more frequent releases than what seems 
to be the case with Aries.


/Bengt
2011/6/27 Alasdair Nottingham n...@apache.org


Hi,
I don't think there are any plans. In the past releases have been more on 
demand.
After the 0.3 release we decided to move to a pre-bundle release process so 
their wont be a big 0.4 release like there were previously. Some bundles might 
be at 0.4 and some at 0.3.1.



Do you need a release?
Alasdair

On 24 June 2011 13:04, Bengt Rodehav be...@rodehav.com wrote:



Anyone know when Aries 0.4 is planned for?
/Bengt


-- 
Alasdair Nottingham
n...@apache.org





  

RE: Attaching jpa persistence.xml via fragments to a persistence bundle

[Timothy Ward]

Hi,

If the properties you are trying to set are configurable when the EntityManager 
is created then you could pass them using EMF#createEntityManager(Map props). 
There's also xml syntax for injecting these with blueprint:

bean id=contextWithProps
jpa:context property=em
  map
entry key=one value=eins /
entry key=two value=zwo /
  /map
/jpa:context
  /bean


If the properties you want to set can only be set at EntityManagerFactory 
creation time then using your own ManagePersistenceUnitInfoFactory is a pretty 
good idea (although it is a reasonably large amount of effort). 
Subclassing/wrapping the existing implementation obviously risks you being 
broken unexpectedly (it's not part of the API).

Regards,

Tim


 Date: Mon, 20 Jun 2011 16:31:02 +0200
 Subject: Re: Attaching jpa persistence.xml via fragments to a persistence 
 bundle
 From: marcel.hanser.w...@googlemail.com
 To: user@aries.apache.org
 
 Thank for you answers,
 
 so a usage of fragments failes I realy reluctant would create n
 (dbms) * m (jpa provider) * k (log level) * etc times bundles,
 with the same classes and just deversity persistence.xml. Do you have
 a best practice for me how to reference a persistence.xml (or just the
 provider specific properties) which is not part of my persistence
 bundle?
 Maybe using a selfwritten
 org.apache.aries.jpa.container.ManagedPersistenceUnitInfoFactory which
 has preconfigured properties/settings for a specific persistence unit
 and merges them?
 
 Regards,
 Marcel
 
 2011/6/20 Timothy Ward timothyjw...@apache.org:
  Hi,
 
  There is another much more important reason to use getEntry, the JPA
  container processes persistence bundles as they are installed to prevent any
  classes being able to be loaded before the metadata can be parsed. We then
  immediately create an EntityManagerFactory as the bundle resolves. If any
  classes were to be loaded before we created the EntityManagerFactory then it
  would not be possible to load-time enhance the entity classes.
 
  Unfortunately there are no fragments attached when the bundle is in the
  INSTALLED state. Using getResource() would cause the bundle to move to
  RESOLVED which we don't want either.
 
  Regards,
 
  Tim
 
  Subject: Re: Attaching jpa persistence.xml via fragments to a persistence
  bundle
  From: n...@apache.org
  Date: Mon, 20 Jun 2011 09:05:29 +0100
  To: user@aries.apache.org
 
  Hi,
 
  getResource does something very different from getEntry. getResource uses
  the Bundle-Classpath so it doesn't guarantee to return
  META-INF/persistence.xml rooted in the bundle. That is why getResource is
  not used.
 
  I don't know why fragments aren't processed, other people in the list can,
  I'm sure, explain why.
 
  Alasdair Nottingham
 
  On 20 Jun 2011, at 07:56, Marcel Hanser
  marcel.hanser.w...@googlemail.com wrote:
 
   Hi,
  
   i would like to attach a persistence.xml, or more percise parts of it,
   to my jpa persistence bundle, since the concrete provider and DBMS
   configuration should be chooseable without modify the persistence
   bundle.
   I scanned a the aries jpa code and found the
   org.apache.aries.jpa.container.ManagedPersistenceUnitInfoFactory
   plug-in point and also the
  
   org.apache.aries.jpa.container.impl.PersistenceBundleHelper.locateFile(Bundle,
   String) method. And now im wondering why using bundle.getEntry(String)
   instead of bundle.getResource(String). Since fragments are not scanned
   when using bundle.getEntry(String).
   So is there already a way for doing that and i just missed it?
  
   Thanks in advance.
  
   Marcel Hanser
 
  

RE: Void factory method

[Timothy Ward]

Hi,

Just a query, but I'm assuming that we can't just new up an instance of the 
Server and inject into the static methods as if they were instance methods on a 
normal bean? I don't believe we do any checking to see whether property setters 
are static or not. This seems like it would be the simplest solution, and 
wouldn't involve adding a new namespace.

Regards,

Tim


 Date: Tue, 22 Feb 2011 21:08:14 +0100
 Subject: Re: Void factory method
 From: gno...@gmail.com
 To: user@aries.apache.org

 As others have indicated, that's clearly outside of the specs.
 However, I see two different improvements we could add to Aries
 Blueprint to support such use cases:

 
 
 
 
 

 or (maybe closer to the underlying jetty model):

 
 init-method=start destroy-method=stop
 
 
 
 
 
 

 I haven't given that a lot of thoughts, and I'm not really sure how/if
 this can actually be implemented ...
 Both could actually be useful I suppose.

 2011/2/22 Łukasz Dywicki :
  Hello,
  I have small problem with Aries. I try to configure jetty with blueprint.
  Jetty requires to register some objects using void methods, for example:
  Server.addConnector(Connector).
 
  I try to use blueprint XML:
 
 
 init-method=start destroy-method=stop
  /
 
 
  depends-on=jersey
 
 
  class=org.eclipse.jetty.server.nio.SelectChannelConnector
 
 
 
 
 
 
  This configuration causes following error:
  org.apache.aries.blueprint - 0.2.0.incubating | Unable to start blueprint
  container for bundle jetty-server
  org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to
  instantiate components
 at
  org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEager
  Components(BlueprintContainerImpl.java:628)[7:org.apache.aries.blueprint:0.2
  .0.incubating]
 at
  org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintC
  ontainerImpl.java:315)[7:org.apache.aries.blueprint:0.2.0.incubating]
 at
  org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintCon
  tainerImpl.java:213)[7:org.apache.aries.blueprint:0.2.0.incubating]
 at
  java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6
  .0_21]
 at
  java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_21
  ]
 at
  java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_21]
 at
  java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$
  301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_21]
 at
  java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Sch
  eduledThreadPoolExecutor.java:207)[:1.6.0_21]
 at
  java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.ja
  va:886)[:1.6.0_21]
 at
  java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:9
  08)[:1.6.0_21]
 at java.lang.Thread.run(Thread.java:619)[:1.6.0_21]
  Caused by: java.lang.NullPointerException
 at
  java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881)[:1.6.
  0_21]
 at
  org.apache.aries.blueprint.container.BlueprintRepository.addPartialObject(Bl
  ueprintRepository.java:357)[7:org.apache.aries.blueprint:0.2.0.incubating]
 at
  org.apache.aries.blueprint.di.AbstractRecipe.addPartialObject(AbstractRecipe
  .java:84)[7:org.apache.aries.blueprint:0.2.0.incubating]
 at
  org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.ja
  va:736)[7:org.apache.aries.blueprint:0.2.0.incubating]
 at
  org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64)[
  7:org.apache.aries.blueprint:0.2.0.incubating]
 at
  org.apache.aries.blueprint.container.BlueprintRepository.createInstances(Blu
  eprintRepository.java:219)[7:org.apache.aries.blueprint:0.2.0.incubating]
 at
  org.apache.aries.blueprint.container.BlueprintRepository.createAll(Blueprint
  Repository.java:147)[7:org.apache.aries.blueprint:0.2.0.incubating]
 at
  org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEager
  Components(BlueprintContainerImpl.java:624)[7:org.apache.aries.blueprint:0.2
  .0.incubating]
 ... 10 more
 
 
 



 --
 Cheers,
 Guillaume Nodet
 
 Blog: http://gnodet.blogspot.com/
 
 Open Source SOA
 http://fusesource.com
  

RE: Spring Aries Tx Manager

[Timothy Ward]

Hi Charles,

The tx:transaction...  element will make use of the 
javax.transaction.TransactionManager service and will commit any transactions 
that it begins as soon as the method invocation on the bean completes. If you 
want the transaction to be created outside the bean you should really be using 
a MANDATORY transaction type for the bean and debugging why the transaction 
isn't being started (according to the javax.transaction.TransactionManager) 
before the service is invoked.

Regards,

Tim


 Date: Wed, 9 Feb 2011 15:41:09 +0100
 Subject: Spring  Aries Tx Manager
 From: cmoulli...@gmail.com
 To: user@aries.apache.org; d...@aries.apache.org

 Hi,

 I have created a project containing a persistence and service layer.
 Transactions demarcations are defined at the level of the service like
 this

 
 interface=org.apache.camel.example.reportincident.service.IncidentService/

 
 class=org.apache.camel.example.reportincident.service.impl.IncidentServiceImpl

 

 
 
 interface=org.apache.camel.example.reportincident.dao.IncidentDAO/
 

 

 Persistence has been defined as presented here after

 
 class=org.apache.camel.example.reportincident.dao.impl.IncidentDAOImpl
 
 

 
 interface=org.apache.camel.example.reportincident.dao.IncidentDAO
 

 From a Camel transactional route, I commit or generate a rollback in
 case of error.

 
 
 class=org.apache.camel.spring.spi.SpringTransactionPolicy
 
 
 interface=org.springframework.transaction.PlatformTransactionManager/
 
 
 

 
 
 
 
 
 
 
 java.lang.Exception
 
 
 
 

 Services exposed :

 Apache Aries Transaction Manager (1896) provides:
 -
 org.osgi.service.cm.ManagedServiceFactory
 javax.transaction.TransactionManager,
 javax.transaction.TransactionSynchronizationRegistry,
 javax.transaction.UserTransaction,
 org.apache.geronimo.transaction.manager.RecoverableTransactionManager,
 org.springframework.transaction.PlatformTransactionManager

 Everything works fine as I'm able from my camel route to call the
 service layer (=POJO) and insert data in the MySQL DB. Unfortunately,
 when I generate an error and a rollback occurs in camel, this one is
 not propagated back and data are inserted.

 Does anybody has a trick to solve this ?

 Regards,

 Charles Moulliard

 Sr. Principal Solution Architect - FuseSource
 Apache Committer

 Blog : http://cmoulliard.blogspot.com
 Twitter : http://twitter.com/cmoulliard
 Linkedin : http://www.linkedin.com/in/charlesmoulliard
 Skype: cmoulliard
  

RE: GRACE_PERIOD for bundle persistence-jpa-aries !!

[Timothy Ward]

Hi Charles,
I'm glad you found the problem here :). An empty Meta-Persistence:  (note the 
trailing space) would also do in this case because META-INF/persistence.xml is 
the default location.

Regards,

Tim


 Date: Wed, 9 Feb 2011 14:57:49 +0100
 Subject: Re: GRACE_PERIOD for bundle persistence-jpa-aries !!
 From: cmoulli...@gmail.com
 To: user@aries.apache.org

 Hi

 I have found the reason. The instruction Meta-Persistence:
 META/persistence.xml was not defined in my bundle.

 Regards,

 Charles Moulliard

 Sr. Principal Solution Architect - FuseSource
 Apache Committer

 Blog : http://cmoulliard.blogspot.com
 Twitter : http://twitter.com/cmoulliard
 Linkedin : http://www.linkedin.com/in/charlesmoulliard
 Skype: cmoulliard



 On Wed, Feb 9, 2011 at 2:28 PM, Charles Moulliard  wrote:
  Hi,
 
  I get the following error when deploying a JPA bundle on Apache Karaf
  and the status of the bundle is GracePeriod
 
  4:20:13,385 | DEBUG | rint Extender: 3 | BlueprintContainerImpl
| container.BlueprintContainerImpl  245 | 8 -
  org.apache.aries.blueprint - 0.3.0.SNAPSHOT | Running blueprint
  container for bundle persistence-jpa-aries in state
  WaitForInitialReferences
  14:20:13,385 | INFO  | rint Extender: 3 | BlueprintContainerImpl
 | container.BlueprintContainerImpl  305 | 8 -
  org.apache.aries.blueprint - 0.3.0.SNAPSHOT | Bundle
  persistence-jpa-aries is waiting for dependencies
  [(((org.apache.aries.jpa.proxy.factory=true)(osgi.unit.name=ReportIncident))(objectClass=javax.persistence.EntityManagerFactory))]
  14:20:13,385 | DEBUG | rint Extender: 3 | BlueprintEventDispatcher
 | ntainer.BlueprintEventDispatcher  123 | 8 -
  org.apache.aries.blueprint - 0.3.0.SNAPSHOT | Sending blueprint
  container event BlueprintEvent[type=GRACE_PERIOD,
  dependencies=[(((org.apache.aries.jpa.proxy.factory=true)(osgi.unit.name=ReportIncident))(objectClass=javax.persistence.EntityManagerFactory))]]
  for bundle persistence-jpa-aries
 
  The persistence.xml file containing the unit ReportIncident is
  packaged in META-INF directory while my blueprint config file in
  OSGI-INF.
 
  Here is the list of bundles deployed :
 
  [1908] [Active ] [] [   ] [   60] Apache
  ServiceMix :: Bundles :: commons-dbcp (1.4.0.1-SNAPSHOT)
  [1909] [Active ] [] [   ] [   60] Sun
  Microsystems' JDBC Driver for MySQL (5.1.9)
  [1910] [Active ] [] [   ] [   60] Apache
  ServiceMix :: Bundles :: aspectj (1.6.8.1)
  [1911] [Active ] [] [   ] [   60] OpenJPA
  Aggregate Jar (2.0.1)
  [1912] [Active ] [] [   ] [   60] Apache
  ServiceMix :: Specs :: Java Persistence API 2.0 (1.6.0)
  [1913] [Active ] [] [   ] [   60] Apache
  ServiceMix Bundles: serp-1.13.1 (1.13.1.2)
  [1914] [Active ] [] [   ] [   60] Apache Aries Util 
  (0.3.0)
  [1915] [Active ] [] [   ] [   60] Apache Aries
  JNDI API (0.3.0)
  [1916] [Active ] [] [   ] [   60] Apache Aries
  JNDI Core (0.3.0)
  [1917] [Active ] [] [   ] [   60] Apache Aries
  JNDI RMI Handler (0.3.0)
  [1918] [Active ] [] [   ] [   60] Apache Aries
  JNDI URL Handler (0.3.0)
  [1919] [Active ] [] [   ] [   60] Apache Aries
  JNDI Support for Legacy Runtimes (0.3.0)
  [1920] [Active ] [Created ] [   ] [   60] Apache Aries
  Transaction Blueprint (0.3.0)
  [1921] [Active ] [] [   ] [   60] Apache Geronimo
  JSR-317 JPA 2.0 Spec API (1.1)
  [1922] [Active ] [Created ] [   ] [   60] Aries JPA
  Container blueprint integration for Aries blueprint (0.3.0)
  [1923] [Active ] [] [   ] [   60] Aries JPA
  Container (0.3.0)
  [1924] [Active ] [] [   ] [   60] Aries JPA
  Container Managed Contexts (0.3.0)
 
  and the content of my bundle
 
  karaf@root headers 1938
 
  Reportincident :: Persistence JPA :: Aries (1938)
  -
  Manifest-Version = 1.0
  Bnd-LastModified = 1297241499732
  Tool = Bnd-0.0.357
  Built-By = charlesmoulliard
  Build-Jdk = 1.6.0_22
  Created-By = Apache Maven Bundle Plugin
 
  Bundle-Name = Reportincident :: Persistence JPA :: Aries
  Bundle-SymbolicName = persistence-jpa-aries
  Bundle-Version = 1.0.0.SNAPSHOT
  Bundle-ManifestVersion = 2
 
  Import-Package =
 com.mysql.jdbc,
 javax.persistence;resolution:=optional;version=[1.1.0,2.1.0),
 
  javax.persistence.criteria;resolution:=optional;version=[1.1.0,2.1.0),
 
  javax.persistence.metamodel;resolution:=optional;version=[1.1.0,2.1.0),
 javax.persistence.spi;resolution:=optional;version=[1.1.0,2.1.0),
 javax.sql;resolution:=optional,
 javax.transaction;resolution:=optional,
 org.apache.camel.dataformat.bindy.annotation;version=2.4,