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.
