| Missing part in understanding OSGI [message #1064049] |
Mon, 17 June 2013 12:10  |
 Franz Martin
Messages: 4
Registered: June 2013 |
Junior Member |
|
|
Dear VIRGO experts,
I need your help to point me in the right direction understanding the osgi concepts. What i don't understand yet is how to use the basic web.xml definition made in a single web bundle (dispatcherServlet, securityFilterChain, ...) in a no web bundle.
For example if I want to design a modular rest api. Then - if I understand osig correctly - it would be possible to do it like this:
Web Bundle
web.xml with dispatcherServlet
springconfig.xml with RequestMappingHandlerMapping, JSON Converter, ...
Non Web Bundle - API parts 1
applicationcontext.xml with various osgi:reference imports form the web bundle like:
RequestMappingHandlerMapping
or other resources defined in other bundles like:
Hibernate datasource
and the bundle content:
Controllers, Services, DAO, etc...
Non Web Bundle - API parts 2
applicationcontext.xml with various osgi:reference imports form the web bundle like:
RequestMappingHandlerMapping
or other resources defined in other bundles like:
Hibernate datasource
and the bundle content:
Controllers, Services, DAO, etc...
The question is now: How to run the part 1 part 2 bundle in the corresponding context of the "central rest api web bundle".
The same question is relevant for spring security settings. Of course i can define a security filter chain in a web bundle as well as the auth manager for example in the corresponding springconfig.xml. It is also no problem to use a reference to the authManger in other bundles. But: I don't understand how to bring the non web bundles in the context of a web bundle. In this case the security filter chain.
Is this VIRGO SNAPS what I am looking for?
Or am I totally on the wrong way with my osgi understanding?
Any help would be fantastic.
Best regards, Martin
|
|
|
| Re: Missing part in understanding OSGI [message #1064054 is a reply to message #1064049] |
Mon, 17 June 2013 12:55  |
|
The way I understand your description you are cutting your single web app in the wrong direction/way.
Perhaps it is possible the way you are trying to do it but we have gone a different direction and it may help you in your quest  :
We have one Persistence API bundle.
We have one bundle for persisting entities which offers itself as a service (via declarative service).
We have one API bundle for the business layer.
We have one bundle which implements the business API and gets a reference to the persistence service injected via declarative service.
We have one web app bundle (WAB) which contains the REST services. This bundle has a bundle activator which contains a service tracker for the business service. (this could probably also be injected somehow)
Hope this helps.
Mihael
|
|
|
|
| Re: Missing part in understanding OSGI [message #1064282 is a reply to message #1064270] |
Tue, 18 June 2013 14:26 |
|
Quote:We have one API bundle for the business layer.
All your services and so on...
Don't you need access to your Bundles B here?
Yes. As said before: The persistence bundle offers service(s). These services can be injected into the business services (one way by declaring a reference in the component definition xml file, see OSGi declarative services).
D: Business API bundle containes the interfaces to the business layer. We use these interfaces in the web bundle to get a service from the OSGi container for the passed interface.
We use interfaces to register services in the OSGi container.
ServiceA implements BusinessInterfaceA
Now we register ServiceA at the OSGi container and say that it implements BusinessInterfaceA (which it does).
Any other object with access to the BundleContext can retrieve ServiceA via the OSGi service registry and ask for a service which implements BusinessInterfaceA.
Exchanging the backend is no problem at all as long as the API stays the same. You would just write new implementations of the interfaces and exchange the bundles. You can just exchange the persistence bundle or the business bundle or both. As we are always using APIs when talking to other bundles exchanging things is easy.
That's one of the good thing about OSGi.
Mihael
|
|
|
|
| Re: Missing part in understanding OSGI [message #1064337 is a reply to message #1064289] |
Tue, 18 June 2013 19:24 |
|
Nothing wrong with splitting things up if you need it in smaller pieces/bundles.
You can also put jpa and "ejb"/business stuff together and split it the other way like having a bundle
crm.customer
and
crm.salesprospects
or you can even further split it into
crm.customer.jpa
crm.customer.ejb
crm.customer.api
crm.customer.rs
For the JPA stuff you probably want shared persistence so that every jpa bundle of yours has the same cache (only from my exp with hybrid apps on glassfish, don't know Gemini JPA yet).
Hope this is of any help.
Mihael
|
|
|
|
Powered by
FUDForum. Page generated in 0.03418 seconds
] 
Search
Help
Register
Login
Home
