I am developing and application as a series of OSGI bundles which will run on Karaf.
The Bundles has a fair bit of interoperability, both exposing a bunch of services, and consuming services from each other.
However, I would very much like to be able to build a WAR file of the application alongside the bundles. There are a few clients that quite simply won't allow an OSGI container on their servers.
So my question is, what is the best way to separate the OSGI service logic from the application logic? The activators are no trouble, as they are just unused in the WAR deployment, but i have a lot of calls that retrives services from the bundlecontext, like bundleContext.getServiceReference(stuffISortOfNeed.class)scattered around my code. bundleContext is currently a static object set by the activator.
This won't do in a WAR container that knows nothing of OSGI.
Is it possible to somehow hide the BundleContext and the getServiceReference calls away from the actual application? Preferably i would love an injection-like approach where i could define my services with #Annotations and define and injector for OSGI and one for PlainOldJava.
To really have POJOs you could use Blueprint XML to register your Web Application Bundle (WAB).
A good example can be found in the pax web project.
By using XML over annotations you only have an extra resource file that can be ignored if you assemble you bundles as libs in a war file, no extra dependencies on specific annotations.
Related
I'm playing around the idea of a very huge vaadin application, which consists of a skeleton (providing the ui framework) and hundreds of functional units (providing the specific vaadin views).
The main architectural point is to let the skeleton be agnostic about the functional units, so not a single java dependency to a functional unit should be injected into skeleton. Every single functional unit has to be in it's own distinct JAR.
The vaadin container is started by the skeleton-module. It is perfectly possible to build a navigation with all the necessary routes to the functional units (/routeToView001.../routeToView999) without having further details about them.
However, I don't see, how the started vaadin spring boot container would load the java classes from the independent JARs when navigation occurs in browser. Practical attempts failed. Any ideas?
The Spring Boot integration is by default looking for #Route classes within the Java package that contains the #SpringBootApplication class. This can be further configured by passing package names to the #EnableVaadin annotation.
I haven't tested this in practice, but it might be possible to have a multiple #EnableVaadin annotations so that there would be one in each module and through that also provide multiple locations to look for #Route classes from. In that case, the #EnableVaadin class in each module would also have to register itself in the same way as any other #Configuration by using the regular Spring Boot autoconfiguration mechanism.
Another alternative is that you register route classes manually to the application's route registry (accessed using ApplicationRouteRegistry.getInstance(new VaadinServletContext(servletContext))). In that case, you might still need to have at least a dummy #Route in the base module since Vaadin might not automatically enable itself in a Spring Boot environment unless at least one #Route class is discovered in the regular way.
I am trying to link an aqueduct server with my existing dart project. I am aware of aqueducts HTTPFileController and how you can serve static files, but I was looking for insight on the best way to integrate a full client side web app written in dart with the aqueduct framework. I.e. making API method calls from the component which say return a list of users or something like that. The RPC package offers something like this, but I would like to use aqueduct as it is more robust and offers more features.
Currently my overall project structure looks like: Any suggestions are appreciated!
my_proj
build
lib
components
(dart components serving html)
controller
(aqueduct controllers)
model
(aqueduct models)
my_proj.dart
my_proj_sink.dart
migrations
test
web
main.dart
index.html
It's a good idea to keep the projects separate. This way you can have separate dependency constraints for both platforms, which will end up being meaningful as your application grows. It will give you the most flexibility in deployment, too.
Here's an example repository; these are works in progress, so the Flutter application is hooked up to the Aqueduct API, while the Angular2 app hasn't been touched. Flutter has a similar component-like approach.
The shared directory will be most interesting to you - it has the model and services for making calls to the API. Both the Flutter and Angular2 apps use it as a dependency.
In this example, the server is run with aqueduct serve --port 8082 from server/ and the web application is run with pub serve from angular2/. As the Dart ecosystem evolves with things like the DDC, you'll likely be best served by adopting a development/deploy pattern like this that works within that toolchain.
If you are planning on serving the generated HTML/CSS/JS files from Aqueduct, a good idea is to have an HTTPFileController reference the build/web folder in your Angular2 project. So, you might have a folder structure like:
project/
server/
pubspec.yaml
lib/
sink.dart
controllers/
model/
client/
pubspec.yaml
lib/
web/
And your route hookup looks like this:
router
.route("/*")
.pipe(new HTTPFileController("../client/build/web"));
Another approach is to have a build script that writes the files into a directory inside the server directory; this might be useful for deploying.
The Aqueduct team is currently looking at different options and building tools for this purpose. With the recent release of DDC, we are focused more on providing a toolchain that works with it. (I'll also see if one of our team members focused on this part of the puzzle can drop in here with some additional thoughts.)
Please feel free to file an issue for this as well so you can track its progress. Likewise, we have folks in Gitter dart-lang/server that answer quickly. Hope this helps.
I have a Service Client Library project which has its own
app.config
.
This project is referenced in my Web Application. The problem is My web application throws following exception
Could not find endpoint element with name 'HttpEndPoint' and contract 'ServiceLibReference1.IDalService' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this name could be found in the client element.
There is nothing wrong with the service. If i directly refer my service in the web application it works fine as client configurations get added to the web.config. But my requirement is to keep it in a separate library project.
The reason for the exception is service configurations are not added to the web.config. Should i always add them manually? Should not VS add corresponding configurations into web.config whenever a service library is referenced? or am i missing something ?
thanks
Service libraries are, by design, intended to be used by (potentially) multiple different applications. Therefore, they don't use the app.config file included in the template - they will use the config file (web/app) of the application that is referencing them. This promotes code reuse - if you have certain methods that you are always using across multiple applications, it's easier to put them in a separate class library assembly. One benefit of that design is that you only need to change the code in one place to make the change effective for all using applications.
So yes, you will always need to add the service configuration to the specific application configuration file. Unfortunately, VS does not know to do this.
I am using struts2 for my web application and i want to use osgi architecture for service and dao layer. Now I dont want to wrap my struts2 actions as osgi bundles but want service and dao layer to be packaged as bundles. Now can anybody tell me how my non osgi actions can consume osgi bundles(service and dao layer). And I want to deploy my struts2 web application in web container so how web container will interact with osgi container(where my service and dao is deployed) in this case . Please help .
You need a so called 'bridge' between your web container and your OSGi environment.
Both Felix and Equinox have that capability, but for me the Felix implementation worked much better.
What you basically want to do is:
Add a context listener to your ServletContext
Starting OSGi when starting the ServletContext, stop it when the ServletContext gets destroyed.
Pass the ServletContext to the OSGi context by registering it as a service
Store the OSGi framework object in the ServletContext by registering it as an attribute.
So to access the web context from OSGi: Retrieve the ServletContext service, and go from there.
To access OSGi from the webcontext: Retrieve the OSGi framework from the ServletContext attribute and go from there.
Check the Felix Documentation, also I've made an example a while back on GitHub
Most surely this will not work. Why do you think it should be a good idea to move half of your application to OSGi? Either you should move all of it or none.
You may be able to deploy the struts layer in a war file and a access the OSGi services from it. I think this is possible in Virgo and Apache Karaf. It means to enhance the war with OSGi structures. For example in Karaf you can use a wab file which is a war file with a Manifest.
I'm writing a Grails app which I'd like 3rd parties to augment at runtime. Ideally they would be able to add a JAR/WAR to the webapp directory which contains new domain, controller and service classes, new views, and other content.
Is there a simple way to do this within grails? Would it be simplest to create a startup script which copies the new classes etc. into the relevant directories and then updates grails.xml and web.xml?
You will be able to do this in version 2 of grails in which plugins will be also OSGI plugins http://jira.codehaus.org/browse/GRAILS/fixforversion/15421
It seems that the Grails plugins will actually fit quite well for this: http://www.grails.org/Understanding+Plugins
A plugin can do just about anything... One thing a plugin cannot do though is modify the web-app/WEB-INF/web.xml or web-app/WEB-INF/applicationContext.xml files. A plugin can participate in web.xml generation, but not modify the file or provide a replacement. A plugin can NEVER change the applicationContext.xml file, but can provide runtime bean definitions