You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Mohammad Shamsi <m....@gmail.com> on 2015/09/02 12:19:34 UTC
Bundle is waiting for namespace handlers [http://aries.apache.org/xmlns/jpa/v1.0.0]
Hi All,
I am upgrading an application from Karaf 3.0.3 to 4.0.1 and facing an
strange JPA related issue.
As it mentioned in the email title, the JPA related bundle is waiting for
JPA namespace handler.
I can see that "Aries JPA Blueprint" version 2.1.0 is started successfully
but it is registering a slightly different namespace handler:
*objectClass = [org.apache.aries.blueprint.NamespaceHandler]*
*osgi.service.blueprint.namespace =
http://aries.apache.org/xmlns/jpan/v1.0.0
<http://aries.apache.org/xmlns/jpan/v1.0.0>*
As you see the url contains "jpan" but not "jpa".
I tried to change the url in the blueprint xml file and add "jpan" instead
of "jpa" but faced another issue in runtime:
*Caused by: org.xml.sax.SAXParseException; cvc-complex-type.2.4.c: The
matching wildcard is strict, but no declaration can be found for element
'jpa:context'.*
Any idea what could be the possible issue?
Regards,
Mohammad Shamsi
Re: Bundle is waiting for namespace handlers [http://aries.apache.org/xmlns/jpa/v1.0.0]
Posted by Mohammad Shamsi <m....@gmail.com>.
Hi JB,
May I have the issue number, if it is already created?
Meanwhile is there any workaround for this problem? (other than downgrading
Aries version)
Thanks,
Mohammad Shamsi
On Wed, 2 Sep 2015 at 13:18 Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi Mohammad,
>
> it sounds like a bug in Aries JPA Blueprint.
>
> I gonna create the Jira and fix that.
>
> Regards
> JB
>
> On 09/02/2015 12:19 PM, Mohammad Shamsi wrote:
> > Hi All,
> >
> > I am upgrading an application from Karaf 3.0.3 to 4.0.1 and facing an
> > strange JPA related issue.
> >
> > As it mentioned in the email title, the JPA related bundle is waiting
> > for JPA namespace handler.
> >
> > I can see that "Aries JPA Blueprint" version 2.1.0 is started
> > successfully but it is registering a slightly different namespace
> handler:
> >
> > */objectClass = [org.apache.aries.blueprint.NamespaceHandler]/
> > *
> > */osgi.service.blueprint.namespace =
> > http://aries.apache.org/xmlns/jpan/v1.0.0/
> > *
> >
> > As you see the url contains "jpan" but not "jpa".
> >
> > I tried to change the url in the blueprint xml file and add "jpan"
> > instead of "jpa" but faced another issue in runtime:
> > */Caused by: org.xml.sax.SAXParseException; cvc-complex-type.2.4.c: The
> > matching wildcard is strict, but no declaration can be found for element
> > 'jpa:context'./*
> > */
> > /*
> > Any idea what could be the possible issue?
> >
> > Regards,
> > Mohammad Shamsi
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Bundle is waiting for namespace handlers
[http://aries.apache.org/xmlns/jpa/v1.0.0]
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Mohammad,
it sounds like a bug in Aries JPA Blueprint.
I gonna create the Jira and fix that.
Regards
JB
On 09/02/2015 12:19 PM, Mohammad Shamsi wrote:
> Hi All,
>
> I am upgrading an application from Karaf 3.0.3 to 4.0.1 and facing an
> strange JPA related issue.
>
> As it mentioned in the email title, the JPA related bundle is waiting
> for JPA namespace handler.
>
> I can see that "Aries JPA Blueprint" version 2.1.0 is started
> successfully but it is registering a slightly different namespace handler:
>
> */objectClass = [org.apache.aries.blueprint.NamespaceHandler]/
> *
> */osgi.service.blueprint.namespace =
> http://aries.apache.org/xmlns/jpan/v1.0.0/
> *
>
> As you see the url contains "jpan" but not "jpa".
>
> I tried to change the url in the blueprint xml file and add "jpan"
> instead of "jpa" but faced another issue in runtime:
> */Caused by: org.xml.sax.SAXParseException; cvc-complex-type.2.4.c: The
> matching wildcard is strict, but no declaration can be found for element
> 'jpa:context'./*
> */
> /*
> Any idea what could be the possible issue?
>
> Regards,
> Mohammad Shamsi
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Bundle is waiting for namespace handlers
[http://aries.apache.org/xmlns/jpa/v1.0.0]
Posted by Christian Schneider <ch...@die-schneider.net>.
The @PersistenceContext, @PersistenceUnit and @Transactional annotations
are evaluated at runtime. So they work with hand written xml as well as
with the
generated one.
The CDI annotions are evaluated at compile time to create the blueprint
xml using the maven-blueprint-plugin. So to use these you need to
generate the xml.
Even if you generate the xml you can add a hand written xml too and both
will then be used together. So for example you can configure cxf
endpoints and clients using xml and still configure the bulk of your
beans using annotations.
Christian
On 16.09.2015 11:09, Achim Nierbeck wrote:
> does that imply you only can use the annotations, and rely on a
> generated blueprint.xml?
>
>
> 2015-09-16 11:05 GMT+02:00 Christian Schneider
> <chris@die-schneider.net <ma...@die-schneider.net>>:
>
> Hi Jochen,
>
> yes this is correct. Aries JPA 2 only uses the annotations.
> In addition I am currently working on a new Aries Transaction 3
> that will then also only use the jta 1.2 annotations.
>
> This means that the whole JPA/JTA setup will then be based on the
> standard set of annotations. The advantage is that you do not need
> any Aries specific imports in your bundle.
>
> I will also release a new maven-blueprint-plugin version that is
> adapted for the new JPA and JTA versions and creates the blueprint
> xml from CDI + JEE annotations. So in the end you can use
> blueprint with almost the same set of annotations like JEE.
>
> Christian
>
>
> On 16.09.2015 10:50, jochenw wrote:
>
> Does this mean that now it is *mandatory *to define the
> persistence unit per
> annotation, and it is no longer possible to define it in the
> blueprint file?
>
> Is this a bug of a feature? Or, in other words, does it make
> sense to open a
> Jira for Aries if I want to get the blueprint.xml mechanism
> back (the
> respective entries seem to be missing in the xsd file)?
>
> Best Regards,
>
> Jochen
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Bundle-is-waiting-for-namespace-handlers-http-aries-apache-org-xmlns-jpa-v1-0-0-tp4042275p4042618.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
> Committer & Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Bundle is waiting for namespace handlers [http://aries.apache.org/xmlns/jpa/v1.0.0]
Posted by Achim Nierbeck <bc...@googlemail.com>.
does that imply you only can use the annotations, and rely on a generated
blueprint.xml?
2015-09-16 11:05 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
> Hi Jochen,
>
> yes this is correct. Aries JPA 2 only uses the annotations.
> In addition I am currently working on a new Aries Transaction 3 that will
> then also only use the jta 1.2 annotations.
>
> This means that the whole JPA/JTA setup will then be based on the standard
> set of annotations. The advantage is that you do not need any Aries
> specific imports in your bundle.
>
> I will also release a new maven-blueprint-plugin version that is adapted
> for the new JPA and JTA versions and creates the blueprint xml from CDI +
> JEE annotations. So in the end you can use blueprint with almost the same
> set of annotations like JEE.
>
> Christian
>
>
> On 16.09.2015 10:50, jochenw wrote:
>
>> Does this mean that now it is *mandatory *to define the persistence unit
>> per
>> annotation, and it is no longer possible to define it in the blueprint
>> file?
>>
>> Is this a bug of a feature? Or, in other words, does it make sense to
>> open a
>> Jira for Aries if I want to get the blueprint.xml mechanism back (the
>> respective entries seem to be missing in the xsd file)?
>>
>> Best Regards,
>>
>> Jochen
>>
>>
>>
>> --
>> View this message in context:
>> http://karaf.922171.n3.nabble.com/Bundle-is-waiting-for-namespace-handlers-http-aries-apache-org-xmlns-jpa-v1-0-0-tp4042275p4042618.html
>> Sent from the Karaf - User mailing list archive at Nabble.com.
>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
--
Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
Software Architect / Project Manager / Scrum Master
Re: Bundle is waiting for namespace handlers
[http://aries.apache.org/xmlns/jpa/v1.0.0]
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
It could make sense to keep "backward" compatibility with both
annotation and XML elements.
I will chat with Christian about that.
Regards
JB
On 09/16/2015 04:50 PM, jochenw wrote:
> Hello Christian,
>
> ok, then my expectation was wrong, that the mechanisms to use annotations or
> definitions in xml always exist in parallel, and one can use the one or the
> other.
>
> So if up to now one decided to use the blueprint.xml file since annotations
> were still in experimental state, it is not possible to completely continue
> with that, since the xml support for some functions is discontinued (here
> jpa:context). These things need to be defined via an annotation.
>
> Will Aries Transaction 3 also be "disruptive", i.e. tx:transaction
> method="*" ... will no longer be supported? Is quite handy if I want to have
> transaction activated for all methods in my persistence bundle, without the
> need to have an annotation for each method.
>
> Please don't get me wrong - it's not a complaint. I just haven't expected
> that blueprint xml support for JPA is deprecated, and want to make sure that
> it is really like this - to we *have *to switch to annotations for JPA and
> maybe JTA (in future). (The Aries documentation still tells that blueprint
> annotations is prototype work ...)
>
> Best Regards,
>
> Jochen
>
>
>
>
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Bundle-is-waiting-for-namespace-handlers-http-aries-apache-org-xmlns-jpa-v1-0-0-tp4042275p4042630.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Bundle is waiting for namespace handlers
[http://aries.apache.org/xmlns/jpa/v1.0.0]
Posted by jochenw <jo...@googlemail.com>.
Yes, this works, I have already tried this. I filed a Jira anyways:
KARAF-3998.
Best Regards,
Jochen
cschneider wrote
> I have done some tests. The problem is indeed the coordinator bundle.
> Normally there should be an error message when installing the
> transaction feature as transaction.blueprint needs the coordinator. I
> think this is a bug in the feature service. Probably this is the reason
> that I did not spot the problem. I only installed jpa/1.0.4 but did not
> fully test it.
>
> There is a simple workaround though.
> Just install the coordinator bundle by hand or in your app feature:
> install -s mvn:org.apache.felix/org.apache.felix.coordinator/1.0.0
>
> Then the transaction.blueprint comes up.
>
> Christian
>
>
>
> On 17.09.2015 09:12, jochenw wrote:
>> Slightly different aspect (don't know whether I should open a new thread,
>> but
>> it is related to this one): with Karaf 4.0.1, I tried to use JPA 1.0.4
>> instead of 2.1.0 - to start with, since switching to annotations will
>> take
>> some time.
>>
>> However, the transaction feature 1.3.0 seems not to work with JPA 1.0.4.
>> The
>> org.apache.aries.transaction.blueprint bundle is just not installed
>> (although the aries-blueprint feature is installed), and when installing
>> and
>> starting it manually, it cannot find org.osgi.service.coordinator -
>> org.apache.felix.coordinator is not part of the JPA 1.0.4 feature. The
>> old
>> transation 1.1.1 is no longer provided with Karaf 4.0.1, at least not
>> with
>> the standard distribution.
>>
>> Of course I have a workaround by building a custom distribution with an
>> adapted enterprise feature file. It would just be convenient if one could
>> simply use the 1.x versions of JPA and JTA with standard Karaf, if the
>> "disruptive" concept stays as it is, it would make switching to Karaf
>> 4.0.1
>> simpler.
>>
>> Best Regards,
>> Jochen
>>
>>
>>
>> --
>> View this message in context:
>> http://karaf.922171.n3.nabble.com/Bundle-is-waiting-for-namespace-handlers-http-aries-apache-org-xmlns-jpa-v1-0-0-tp4042275p4042641.html
>> Sent from the Karaf - User mailing list archive at Nabble.com.
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
--
View this message in context: http://karaf.922171.n3.nabble.com/Bundle-is-waiting-for-namespace-handlers-http-aries-apache-org-xmlns-jpa-v1-0-0-tp4042275p4042647.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Bundle is waiting for namespace handlers
[http://aries.apache.org/xmlns/jpa/v1.0.0]
Posted by Christian Schneider <ch...@die-schneider.net>.
I have done some tests. The problem is indeed the coordinator bundle.
Normally there should be an error message when installing the
transaction feature as transaction.blueprint needs the coordinator. I
think this is a bug in the feature service. Probably this is the reason
that I did not spot the problem. I only installed jpa/1.0.4 but did not
fully test it.
There is a simple workaround though.
Just install the coordinator bundle by hand or in your app feature:
install -s mvn:org.apache.felix/org.apache.felix.coordinator/1.0.0
Then the transaction.blueprint comes up.
Christian
On 17.09.2015 09:12, jochenw wrote:
> Slightly different aspect (don't know whether I should open a new thread, but
> it is related to this one): with Karaf 4.0.1, I tried to use JPA 1.0.4
> instead of 2.1.0 - to start with, since switching to annotations will take
> some time.
>
> However, the transaction feature 1.3.0 seems not to work with JPA 1.0.4. The
> org.apache.aries.transaction.blueprint bundle is just not installed
> (although the aries-blueprint feature is installed), and when installing and
> starting it manually, it cannot find org.osgi.service.coordinator -
> org.apache.felix.coordinator is not part of the JPA 1.0.4 feature. The old
> transation 1.1.1 is no longer provided with Karaf 4.0.1, at least not with
> the standard distribution.
>
> Of course I have a workaround by building a custom distribution with an
> adapted enterprise feature file. It would just be convenient if one could
> simply use the 1.x versions of JPA and JTA with standard Karaf, if the
> "disruptive" concept stays as it is, it would make switching to Karaf 4.0.1
> simpler.
>
> Best Regards,
> Jochen
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Bundle-is-waiting-for-namespace-handlers-http-aries-apache-org-xmlns-jpa-v1-0-0-tp4042275p4042641.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Bundle is waiting for namespace handlers
[http://aries.apache.org/xmlns/jpa/v1.0.0]
Posted by Christian Schneider <ch...@die-schneider.net>.
It is the plan to also provide jpa and jta 1.x for karaf 4.
The problem here is that I forgot to also add the coordinator bundle to
the transaction feature. When it is used together with jpa 2 the problem
does not show so I missed this.
Can you open an issue for it?
Christian
On 17.09.2015 09:12, jochenw wrote:
> Slightly different aspect (don't know whether I should open a new thread, but
> it is related to this one): with Karaf 4.0.1, I tried to use JPA 1.0.4
> instead of 2.1.0 - to start with, since switching to annotations will take
> some time.
>
> However, the transaction feature 1.3.0 seems not to work with JPA 1.0.4. The
> org.apache.aries.transaction.blueprint bundle is just not installed
> (although the aries-blueprint feature is installed), and when installing and
> starting it manually, it cannot find org.osgi.service.coordinator -
> org.apache.felix.coordinator is not part of the JPA 1.0.4 feature. The old
> transation 1.1.1 is no longer provided with Karaf 4.0.1, at least not with
> the standard distribution.
>
> Of course I have a workaround by building a custom distribution with an
> adapted enterprise feature file. It would just be convenient if one could
> simply use the 1.x versions of JPA and JTA with standard Karaf, if the
> "disruptive" concept stays as it is, it would make switching to Karaf 4.0.1
> simpler.
>
> Best Regards,
> Jochen
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Bundle-is-waiting-for-namespace-handlers-http-aries-apache-org-xmlns-jpa-v1-0-0-tp4042275p4042641.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Bundle is waiting for namespace handlers
[http://aries.apache.org/xmlns/jpa/v1.0.0]
Posted by jochenw <jo...@googlemail.com>.
Slightly different aspect (don't know whether I should open a new thread, but
it is related to this one): with Karaf 4.0.1, I tried to use JPA 1.0.4
instead of 2.1.0 - to start with, since switching to annotations will take
some time.
However, the transaction feature 1.3.0 seems not to work with JPA 1.0.4. The
org.apache.aries.transaction.blueprint bundle is just not installed
(although the aries-blueprint feature is installed), and when installing and
starting it manually, it cannot find org.osgi.service.coordinator -
org.apache.felix.coordinator is not part of the JPA 1.0.4 feature. The old
transation 1.1.1 is no longer provided with Karaf 4.0.1, at least not with
the standard distribution.
Of course I have a workaround by building a custom distribution with an
adapted enterprise feature file. It would just be convenient if one could
simply use the 1.x versions of JPA and JTA with standard Karaf, if the
"disruptive" concept stays as it is, it would make switching to Karaf 4.0.1
simpler.
Best Regards,
Jochen
--
View this message in context: http://karaf.922171.n3.nabble.com/Bundle-is-waiting-for-namespace-handlers-http-aries-apache-org-xmlns-jpa-v1-0-0-tp4042275p4042641.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Bundle is waiting for namespace handlers
[http://aries.apache.org/xmlns/jpa/v1.0.0]
Posted by jochenw <jo...@googlemail.com>.
Ok, thanks, Christian, for the detailed explanation. I got the idea. Looks
fair enough to me to stay with the 1.x version for keeping the xml
definitions, and then to move towards annotations with the new versions.
You might think about adding your explanation to the Aries docu. It's not so
easy to distinguish what is interpreted during compile time, what during
runtime, and how the maven blueprint plugin fits in.
Best Regards,
Jochen
--
View this message in context: http://karaf.922171.n3.nabble.com/Bundle-is-waiting-for-namespace-handlers-http-aries-apache-org-xmlns-jpa-v1-0-0-tp4042275p4042635.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Bundle is waiting for namespace handlers [http://aries.apache.org/xmlns/jpa/v1.0.0]
Posted by Achim Nierbeck <bc...@googlemail.com>.
I wasn't aware of this fact, and I find it rather disturbing.
Till now I was under the impression that the maven-blueprint-plugin was
just another complementary way of creating the blueprint.xml
Not a replacement. Especially since those annotations are just build-time
and not runtime annotations and there is no way of using std. CDI
annotations for Blueprint beans, I can't see much of a benefit.
And while at it, you remember spring? Spring can always be configured in
two ways and even mixed. Therefore this is very worrying for me.
Cause that Announcement was as clear as your statement right now.
regards, Achim
2015-09-16 19:39 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
> Your are not wrong Aries JPA 2 and Aries transaction 3 will be annotation
> only.
> You will only have the enable elements in the xml. This was announced
> quite a while ago on the dev list.
> In fact the disruptive nature is why both are major versions.
>
> The JPA and JTA annotations are not related in any way to the old
> blueprint annotation support.
> The old blueprint annotations were completely Aries proprietary. As far as
> I know they were never really used much.
>
> The maven-blueprint-plugin is also unrelated to the old blueprint
> annotation support.
> My goal for all these developments is to rely as much on standard
> annotations as possible. I think the reason why the old blueprint
> annotations never took off is that they introduced one more proprietary
> injection model. People are not willing to throw all they learned over board
> and learn some proprietary model that will even lock them in. Another
> argument for the standard annotations is that we need much less
> documentation as
> they are well documented in the standards.
>
> About the xml support for JPA and JTA. It would have been possible to keep
> it but I do not really see a big advantage for the xml. It is much more
> verbose and made the
> code quite complicated. The new code for JPA and JTA is much simpler to
> read and maintain.
>
> If you want to keep with the xml support then you can stay on the 1.x
> versions. The IBM developers on Aries announced that they will keep using
> them for quite some while.
> So I hope they will provide maintenance releases.
>
> Btw. For the new annotations you do not need to annotate each method. You
> can use @Transactional on the class level and override on methods were you
> need different behaviour.
>
> Christian
>
>
> Am 16.09.2015 um 16:50 schrieb jochenw:
>
>> Hello Christian,
>>
>> ok, then my expectation was wrong, that the mechanisms to use annotations
>> or
>> definitions in xml always exist in parallel, and one can use the one or
>> the
>> other.
>>
>> So if up to now one decided to use the blueprint.xml file since
>> annotations
>> were still in experimental state, it is not possible to completely
>> continue
>> with that, since the xml support for some functions is discontinued (here
>> jpa:context). These things need to be defined via an annotation.
>>
>> Will Aries Transaction 3 also be "disruptive", i.e. tx:transaction
>> method="*" ... will no longer be supported? Is quite handy if I want to
>> have
>> transaction activated for all methods in my persistence bundle, without
>> the
>> need to have an annotation for each method.
>>
>> Please don't get me wrong - it's not a complaint. I just haven't expected
>> that blueprint xml support for JPA is deprecated, and want to make sure
>> that
>> it is really like this - to we *have *to switch to annotations for JPA and
>> maybe JTA (in future). (The Aries documentation still tells that blueprint
>> annotations is prototype work ...)
>>
>> Best Regards,
>>
>> Jochen
>>
>>
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://karaf.922171.n3.nabble.com/Bundle-is-waiting-for-namespace-handlers-http-aries-apache-org-xmlns-jpa-v1-0-0-tp4042275p4042630.html
>> Sent from the Karaf - User mailing list archive at Nabble.com.
>>
>
>
--
Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
Software Architect / Project Manager / Scrum Master
Re: Bundle is waiting for namespace handlers
[http://aries.apache.org/xmlns/jpa/v1.0.0]
Posted by Christian Schneider <ch...@die-schneider.net>.
Your are not wrong Aries JPA 2 and Aries transaction 3 will be
annotation only.
You will only have the enable elements in the xml. This was announced
quite a while ago on the dev list.
In fact the disruptive nature is why both are major versions.
The JPA and JTA annotations are not related in any way to the old
blueprint annotation support.
The old blueprint annotations were completely Aries proprietary. As far
as I know they were never really used much.
The maven-blueprint-plugin is also unrelated to the old blueprint
annotation support.
My goal for all these developments is to rely as much on standard
annotations as possible. I think the reason why the old blueprint
annotations never took off is that they introduced one more proprietary
injection model. People are not willing to throw all they learned over board
and learn some proprietary model that will even lock them in. Another
argument for the standard annotations is that we need much less
documentation as
they are well documented in the standards.
About the xml support for JPA and JTA. It would have been possible to
keep it but I do not really see a big advantage for the xml. It is much
more verbose and made the
code quite complicated. The new code for JPA and JTA is much simpler to
read and maintain.
If you want to keep with the xml support then you can stay on the 1.x
versions. The IBM developers on Aries announced that they will keep
using them for quite some while.
So I hope they will provide maintenance releases.
Btw. For the new annotations you do not need to annotate each method.
You can use @Transactional on the class level and override on methods
were you need different behaviour.
Christian
Am 16.09.2015 um 16:50 schrieb jochenw:
> Hello Christian,
>
> ok, then my expectation was wrong, that the mechanisms to use annotations or
> definitions in xml always exist in parallel, and one can use the one or the
> other.
>
> So if up to now one decided to use the blueprint.xml file since annotations
> were still in experimental state, it is not possible to completely continue
> with that, since the xml support for some functions is discontinued (here
> jpa:context). These things need to be defined via an annotation.
>
> Will Aries Transaction 3 also be "disruptive", i.e. tx:transaction
> method="*" ... will no longer be supported? Is quite handy if I want to have
> transaction activated for all methods in my persistence bundle, without the
> need to have an annotation for each method.
>
> Please don't get me wrong - it's not a complaint. I just haven't expected
> that blueprint xml support for JPA is deprecated, and want to make sure that
> it is really like this - to we *have *to switch to annotations for JPA and
> maybe JTA (in future). (The Aries documentation still tells that blueprint
> annotations is prototype work ...)
>
> Best Regards,
>
> Jochen
>
>
>
>
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Bundle-is-waiting-for-namespace-handlers-http-aries-apache-org-xmlns-jpa-v1-0-0-tp4042275p4042630.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Bundle is waiting for namespace handlers
[http://aries.apache.org/xmlns/jpa/v1.0.0]
Posted by jochenw <jo...@googlemail.com>.
Hello Christian,
ok, then my expectation was wrong, that the mechanisms to use annotations or
definitions in xml always exist in parallel, and one can use the one or the
other.
So if up to now one decided to use the blueprint.xml file since annotations
were still in experimental state, it is not possible to completely continue
with that, since the xml support for some functions is discontinued (here
jpa:context). These things need to be defined via an annotation.
Will Aries Transaction 3 also be "disruptive", i.e. tx:transaction
method="*" ... will no longer be supported? Is quite handy if I want to have
transaction activated for all methods in my persistence bundle, without the
need to have an annotation for each method.
Please don't get me wrong - it's not a complaint. I just haven't expected
that blueprint xml support for JPA is deprecated, and want to make sure that
it is really like this - to we *have *to switch to annotations for JPA and
maybe JTA (in future). (The Aries documentation still tells that blueprint
annotations is prototype work ...)
Best Regards,
Jochen
--
View this message in context: http://karaf.922171.n3.nabble.com/Bundle-is-waiting-for-namespace-handlers-http-aries-apache-org-xmlns-jpa-v1-0-0-tp4042275p4042630.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Bundle is waiting for namespace handlers
[http://aries.apache.org/xmlns/jpa/v1.0.0]
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
It sounds good, and it's what I leverage in karaf-boot (with the @jpa
annotation which creates the persistence.xml for you).
Regards
JB
On 09/16/2015 11:05 AM, Christian Schneider wrote:
> Hi Jochen,
>
> yes this is correct. Aries JPA 2 only uses the annotations.
> In addition I am currently working on a new Aries Transaction 3 that
> will then also only use the jta 1.2 annotations.
>
> This means that the whole JPA/JTA setup will then be based on the
> standard set of annotations. The advantage is that you do not need any
> Aries specific imports in your bundle.
>
> I will also release a new maven-blueprint-plugin version that is adapted
> for the new JPA and JTA versions and creates the blueprint xml from CDI
> + JEE annotations. So in the end you can use blueprint with almost the
> same set of annotations like JEE.
>
> Christian
>
> On 16.09.2015 10:50, jochenw wrote:
>> Does this mean that now it is *mandatory *to define the persistence
>> unit per
>> annotation, and it is no longer possible to define it in the blueprint
>> file?
>>
>> Is this a bug of a feature? Or, in other words, does it make sense to
>> open a
>> Jira for Aries if I want to get the blueprint.xml mechanism back (the
>> respective entries seem to be missing in the xsd file)?
>>
>> Best Regards,
>>
>> Jochen
>>
>>
>>
>> --
>> View this message in context:
>> http://karaf.922171.n3.nabble.com/Bundle-is-waiting-for-namespace-handlers-http-aries-apache-org-xmlns-jpa-v1-0-0-tp4042275p4042618.html
>>
>> Sent from the Karaf - User mailing list archive at Nabble.com.
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Bundle is waiting for namespace handlers
[http://aries.apache.org/xmlns/jpa/v1.0.0]
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Jochen,
yes this is correct. Aries JPA 2 only uses the annotations.
In addition I am currently working on a new Aries Transaction 3 that
will then also only use the jta 1.2 annotations.
This means that the whole JPA/JTA setup will then be based on the
standard set of annotations. The advantage is that you do not need any
Aries specific imports in your bundle.
I will also release a new maven-blueprint-plugin version that is adapted
for the new JPA and JTA versions and creates the blueprint xml from CDI
+ JEE annotations. So in the end you can use blueprint with almost the
same set of annotations like JEE.
Christian
On 16.09.2015 10:50, jochenw wrote:
> Does this mean that now it is *mandatory *to define the persistence unit per
> annotation, and it is no longer possible to define it in the blueprint file?
>
> Is this a bug of a feature? Or, in other words, does it make sense to open a
> Jira for Aries if I want to get the blueprint.xml mechanism back (the
> respective entries seem to be missing in the xsd file)?
>
> Best Regards,
>
> Jochen
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Bundle-is-waiting-for-namespace-handlers-http-aries-apache-org-xmlns-jpa-v1-0-0-tp4042275p4042618.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Bundle is waiting for namespace handlers
[http://aries.apache.org/xmlns/jpa/v1.0.0]
Posted by jochenw <jo...@googlemail.com>.
Does this mean that now it is *mandatory *to define the persistence unit per
annotation, and it is no longer possible to define it in the blueprint file?
Is this a bug of a feature? Or, in other words, does it make sense to open a
Jira for Aries if I want to get the blueprint.xml mechanism back (the
respective entries seem to be missing in the xsd file)?
Best Regards,
Jochen
--
View this message in context: http://karaf.922171.n3.nabble.com/Bundle-is-waiting-for-namespace-handlers-http-aries-apache-org-xmlns-jpa-v1-0-0-tp4042275p4042618.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Bundle is waiting for namespace handlers [http://aries.apache.org/xmlns/jpa/v1.0.0]
Posted by Mohammad Shamsi <m....@gmail.com>.
Hi Ellirael,
Thanks for the hint.
Using the new approach, annotation based EntityManager, the startup was
successful.
Cheers,
On Mon, 7 Sep 2015 at 12:13 ellirael <el...@mail.ru> wrote:
> Mohammad, things changed slightly in karaf 4.
>
> Check this page: http://aries.apache.org/modules/jpaproject.html.
>
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Bundle-is-waiting-for-namespace-handlers-http-aries-apache-org-xmlns-jpa-v1-0-0-tp4042275p4042371.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
Re: Bundle is waiting for namespace handlers
[http://aries.apache.org/xmlns/jpa/v1.0.0]
Posted by ellirael <el...@mail.ru>.
Mohammad, things changed slightly in karaf 4.
Check this page: http://aries.apache.org/modules/jpaproject.html.
--
View this message in context: http://karaf.922171.n3.nabble.com/Bundle-is-waiting-for-namespace-handlers-http-aries-apache-org-xmlns-jpa-v1-0-0-tp4042275p4042371.html
Sent from the Karaf - User mailing list archive at Nabble.com.