Thanks Tim, I'm sorry if I didn't thank you immediately but I hate "thank you email" :) so I prefer say thanks only if I need further help like in this case ;)
Unfortunately I have decided to give up the process of converting spring beans in OSGI components because Spring was largely used and I'm not able to carry it out.
So I came back and in my web-app I have embedded the dependency in which beans are declared, said in different words: before I have separated web-app and module in two different bundles, while now I have only one main bundle, the web-app and an embedded dependency containing Spring stuff.
My current problem is this when I start the webapp:
Wrapped by: org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Failed to import bean definitions from URL location [classpath*:spring/appctx-wr-*.xml]
Offending resource: class path resource [application-context.xml]; nested exception is org.springframework.beans.factory.parsing.BeanDefinitionParsingException:
Configuration problem: Unable to locate Spring NamespaceHandler for XML schema
namespace [http://cxf.apache.org/jaxrs]
I'm not finding the solution, org.apache.cxf.cxf-rt-frontend-jaxrs exists as bundle and it is in resolved status, so why a different bundle can't find the NapespaceHandler for that?
Thanks, as always, girls and guys, bye
Raffaele Gambelli
-----osgi-dev-boun...@mail.osgi.org ha scritto: -----
Per: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
Da: Tim Ward
Inviato da: osgi-dev-boun...@mail.osgi.org
Data: 28/07/2017 07.27PM
Oggetto: Re: [osgi-dev] Spring Dynamic Modules is the solution to access bean from a bundle configured in a different bundle?
Da: Tim Ward
Inviato da: osgi-dev-boun...@mail.osgi.org
Data: 28/07/2017 07.27PM
Oggetto: Re: [osgi-dev] Spring Dynamic Modules is the solution to access bean from a bundle configured in a different bundle?
Hi Rafaelle,
I would recommend not using the Felix SCR annotations, and just using the
org.osgi.service.component.annotations (which are the standard ones). You also do not then need the maven-scr-plugin at all.
The standard annotations are automatically processed by both the bnd-maven-plugin and the maven-bundle-plugin. By duplicating this processing you are probably confusing things.
Personally I prefer the bnd-maven-plugin to the maven-bundle-plugin, but either way you should use a newer version. Bnd has just released version 3.4, so 3.0 is getting a bit old to use in a greenfield project!
Finally - don't write a component xml by hand, every time you do an OSGi fairy dies (and the bnd team get very sad!).
Regards,
Tim
Sent from my iPhone
Really thanks guys, I'm studying the issues you have pointed me out, I would like to really become more experienced with this technology.I'm playing with @component and standard annotations and I'm facing a little problem with maven-scr-plugin, when I run build command I receive:Bundle .... : Service-Component entry can not be located in JAR: OSGI-INF/.....
I'm using maven-scr-plugin 1.24.0 with scr goal and I've added these dependencies:org.osgi.core 6.0.0org.apache.felix.scr.ds-annotations 1.2.8org.osgi.service.component.annotations 1.3.0
maven-bundle-plugin 3.0.1Running maven with -X it shows also that I'm using:Tool: Bnd-3.0.0.201509101326Could it be a bug, should I write component xml by hand?Thanks, best regards
Raffaele Gambelli
-----osgi-dev-boun...@mail.osgi.org ha scritto: -----
Per: OSGi Developer Mail List < osgi-dev@mail.osgi.org>
Da: Toni Menzel
Inviato da: osgi-dev-boun...@mail.osgi.org
Data: 19/07/2017 01.58PM
Oggetto: Re: [osgi-dev] Spring Dynamic Modules is the solution to access bean from a bundle configured in a different bundle?
@Dirk true. Thanks for writing it up. I mostly like the references at the very end. Just added it to the (public) OSGi Link list I used to maintain for a while [1].
OSGi tutorials on the web can be very confusing since they are either
- outdated (like the Spring DM examples)
- or somewhat opinionated (Enroute)
- or piecework where you need to be lucky to meet a knowledgable person (Stackoverflow) -> and hope it does not lead you deeper into the (wrong) rabbit hole.
I’d consider Enroute a good starting-point for OSGi (it was intended for that purpose) but somehow Raffaele did not stumble over it. Probably because it does not address architecture renovation/refactoring from non-OSGi to OSGi very much?
Toni
[1] https://github.com/rebaze/awesome-osgi.
www.rebaze.de | www.rebaze.com | @rebazeio
On 19. Jul 2017, 13:13 +0200, Fauth Dirk (AA-AS/EIS2-EU) < dirk.fa...@de.bosch.com>, wrote:
I would also suggest to use OSGi DS and not Spring DM. Spring surely also has its advantages. But if you want to go the OSGi way, Spring does not sound to be a good partner anymore. IIRC Spring even removed the OSGi meta-data from their releases.
@Toni
The introduction is only posted on the vogella blog, but it is not written by him. But thanks that you like it. J
Mit freundlichen Grüßen / Best regards
Dirk Fauth
Automotive Service Solutions, ESI application (AA-AS/EIS2-EU)
Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY | www.bosch.com
Tel. +49 7153 666-1155 | dirk.fa...@de.bosch.com
Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar Denner,
Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. Markus Heyn, Dr. Dirk Hoheisel,
Christoph Kübel, Uwe Raschke, Peter Tyroller
Von: osgi-dev-boun...@mail.osgi.org [ mailto:osgi-dev-boun...@mail.osgi.org] Im Auftrag von Toni Menzel
Gesendet: Mittwoch, 19. Juli 2017 12:13
An: osgi-dev@mail.osgi.org; OSGi Developer Mail List < osgi-dev@mail.osgi.org>
Betreff: Re: [osgi-dev] Spring Dynamic Modules is the solution to access bean from a bundle configured in a different bundle?
Hey Raffaele,
the question is, do you want to keep using Spring as your DI container.
Spring DM is (at least the original one) long dead. SpringSource (at the time) lost faith in OSGi (i’d blame Springs horrendous internals).
The Spring-DM idea, having a spring compatible “API” playing nicely inside OSGi got “standardised” in the for of OSGI Blueprint [1].
You may look into those instead.
But, if you are getting started with OSGi and can rework many parts of your platform (how you do the refactoring is a very different thing to talk about), you may want to have a look at Declarative Services, as it is probably the most OSGi-native way of doing dependency injection in OSGi [2].
[1] Blueprint is part of the OSGi Compendium specification. Just check chapter 121. Aries Docs about Blueprint (implementation): http://aries.apache.org/modules/blueprint.html.
[2] Declarative Services is part of the OSGi Compendium specification. Just check chapter 112. Lars Vogel also has a very good intro incl. well linked further references: http://blog.vogella.com/2016/06/21/getting-started-with-osgi-declarative-services/
@All, can’t the OSGi specs be web-pages, so we can link them like anything else on the web? Or is it just me?
Toni
www.rebaze.de | www.rebaze.com |@rebazeio
On 19. Jul 2017, 11:52 +0200, Raffaele Gambelli < r.gambe...@hitachi-systems-cbt.com>, wrote:
Sorry, I submit again the same question because in the previous one I forgot the subject
Hi all, this is my first question in this list.
I'm trying to adjust a quite complex system, made with OSGI but which was made quite badly, in addition I have to say that I have no so much experience with OSGI.
Briefly, I have four webapps on jetty which should live inside the same Equinox runtime, till today they and their needed bundles have been deployed in a such a way that quite all bundles embedded all their dependencies, so there is a huge confusion.... while I'm hardly working to create very smaller bundles, emptying them from the embedded dependencies and making them work together in what I believe be the OSGI paradygm.
Just to let you know some other elements helping to understand my problems and knowledge here it is a question posted some weeks ago https://stackoverflow.com/questions/44897956/deploy-webapp-in-jetty-in-osgi where a very kind person exhaustively answered.
Now i explain my current problem, I'm finally arrived to have a running webapplication, but as soon as it accesses Spring bean, it is not found, so for example I have a NPE in a row like this:
SessionDao sessionDao = (SessionDao) SpringContextProvider.getApplicationContext().getBean("sessionDao");
That bean is configured in a different bundle and for what I'm undestanding that is the matter, so after some research I arrived to "Spring Dynamic Modules", so I'm reading this http://docs.spring.io/osgi/docs/current/reference/html-single/#why-Spring DM
so my question is, am I on the right path? Should I go deeply with Spring DM to configure bean in bundle A and make it available on bundle B?
Thanks very much, bye
Raffaele Gambelli
element
Font
font-family
font-size
font-style
font-variant
font-weight
letter-spacing
line-height
text-decoration
text-align
text-indent
text-transform
white-space
word-spacing
color
Background
bg-attachment
bg-color
bg-image
bg-position
bg-repeat
Box
width
height
border-top
border-right
border-bottom
border-left
margin
padding
max-height
min-height
max-width
min-width
outline-color
outline-style
outline-width
Positioning
position
top
bottom
right
left
float
display
clear
z-index
List
list-style-image
list-style-type
list-style-position
Table
vertical-align
border-collapse
border-spacing
caption-side
empty-cells
table-layout
Effects
text-shadow
-webkit-box-shadow
border-radius
Other
overflow
cursor
visibility
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
