I have a web application running in a servlet container (Tomcat). My plan is to use hot plug in order to add and remove additional modules to the running web application.
These additional modules just contain some business logic but not any web related stuff like servlets, JSP pages or HTML files.
What is the best way to do this?
I thought about switching from Tomcat to Glassfish in order to use OSGi.
I also thought about using Apache Felix with Tomcat.
What are the alternatives?
OSGi is definitely the right technology if you want to create a modular application that can be updated quickly without downtime.
You have a couple of choices:
You can start with an OSGi container like Apache Felix, and deploy bundles into that container for both your application and a webserver (most of them are based on Jetty). That way, everything is a bundle and can be updated if needed. If you're starting from scratch and have no constraints on existing servlet containers that you must use, this is the way to go.
If you have to keep working with your existing servlet container, you can deploy a WAR that embeds an OSGi container and the OSGi container will load all the bundles that make up your application. In this case, you can deploy a special "bridge" bundle that will register Servlets and Filters with the "host" servlet container.
Starting with Glassfish is a bit like the first option, since Glassfish itself is built on Felix. You just get a lot of "extra" bundles pre-installed in your application. If you use 80% of those anyway, that is probably worth it. If you hardly use any of Glassfish's (JavaEE) features in your application, you're probably better off starting with just Felix and selecting components there.
Related
As per my understanding when developing with CQ5, service layer will be located on the OSGI bundle. Does that mean for every service classes that I will create it will be equivalent to one OSGI Bundle? For example if I have 3 services for my CQ5 application namely: Login Service, UserManagement Service, Registration Service does it mean that there will be also 3 OSGI bundles to be deployed? and how does this bundles will communicate with each other?
Not really. Bundles are more like modules. So you can split your services into bundles basing on their functionality or if you would like to reuse them in other projects. For example you can have next structure:
projectname-core: there you can have services, which can be used by other project as well. Like some content feed generators for external services, Log-in service (if it will be useful in other project as well:
projectname-ui-beans: there you can have beans, which you will be injecting on your jsp pages;
projectname-services: general services, which are specific for this project, like search or registration;
projectname-taglib: there you have your own jsp tags implementation;
projectname-it-test: bundle with integration tests;
projectname-some-specific-stuff: there can be some services which are not dependent on any other bundle, like one-time content manipulation;
Refer this topic for basic structure and Maven archetype for creating it.
Upd1: Communication between bundles can be done in two ways:
you can have one of your bundles as a dependency for another bundle. Then, you could just use #Reference to get services from other bundle
also you can use events to do communication, see this for details.
Having small, focused bundles is good in my opinion, but it doesn't necessarily mean one bundle per service. In your case, login, user management and registration look sufficiently different to warrant their own bundles. But user management for example might be implemented by several services, all provided by the same bundle.
A good rule of thumb is to design your bundles so that removing one of them disables a consistent unit of functionality. Removing your "user management" bundle for example would disable all user management features, ideally without affecting login or registration.
As for communication, think in services. Using Declarative Services, OSGi components simply declare which services they require (usually using #Reference annotations) and the framework takes care of only starting a component once all the services that it requires are available.
I have an existing group of bundles that together create a web application (including an instance of Jetty). A new requirement is to extend this application to provide a RESTful api (using JAX-RS).
I was able to develop the majority of the RESTful API in isolation, away from the rest of the applciation. Without realising, the Apache CXF bundle I was using contained its own Jetty instance. So, in isolation, this worked fine. When I merged the two halves of the application, the two instances' addresses conflicted.
This much I know for sure.
What I do not know is how to re-configure the RESTful API part of the application (JAX-RS) to use the existing Jetty instance. This page suggests the use of CXFServlet, but I cannot find much information on this.
Could anybody shed some light or point me in the right direction?
Edit: I should also mention that, currently, my endpoints use the JAX-RS annotations in a Java interface to map between an endpoint and mapped class. I would prefer to keep this configuration method as opposed to XML or any other method.
One option, which does not use Apache CXF, is to use the web components of Amdatu, which also support JAX-RS annotations. You can find more documentation about them at http://amdatu.org/components/web.html which explains how to setup your project with a separate Jetty instance. You might also want to watch the video at http://amdatu.org/howto/createwebapp.html which deals with the same subject.
If you really want to use Apache CXF, there are two versions: an "all in one" that is pretty much self-contained (and therefore also includes Jetty) and a "modular" one that consists of many separate bundles. The latter in theory gives you the option to integrate with your own copy of Jetty, but you need to figure out what exact set of bundles you need based on their documentation at http://cxf.apache.org/docs/index.html
I'm just new with drools and web development, I'm just wondering if how can i integrate Drools in a Web Application, I'm using JSP and Servlet technology if I'm not mistaken with the term. I'm also planning of using MVC pattern not SpringMVC.
What I already done is:
Downloaded Drools and jBPM as plug-in in eclipse ( Able to create a Drools Project as a proof)
Already create a Dynamic Web Project, running and using Tomcat as a server
My question is where should i put Drool library for me to use the rules depends on the user's input in a JSP? Or if i missing something kindly tell me.
In general, libraries (jar files) should be put in the WEB-INF/lib folder of your web application, which can then be packaged as a whole in a .war file. Tomcat (or whichever servlet container you decide to use) will then load them in the classpath as part of its webapp initialisation. Drools might require specific configuration to tell it where it will find the rule files to load them, check the Drools documentation for that.
I can assure you it works from within a web app and also within an application using the Spring framework. I've seen it work with web services using JAX-WS (Apache CXF) with Spring on Tomcat exposing web services which use Drools to determine what business logic to apply.
I'm working on a project that have several webapps (WARs) built with Maven and deployed in a Java EE.
These WARs share several common business JARS (like one containing domain objects which are loaded from hibernate) and other framework JARs like Spring and Hibernate.
They use Spring MVC, and the Application Context loads Hibernate. As each WAR has its own Classpath in the servlet container, the Hibernate cache (EHcache) is not shared.
What I'd like is to share the cache and also the hibernate session factory bean (as well as other common beans) betweeen the different WARs. I think this is possible by repackaging those WARs inside an EAR and then I'd have to make a spring configuration XML using those commons beans and in the WAR's Spring XML use something like SingletonBeanFactoryLocator from what I've read.
What I'm asking here is if there is a simple way to do this, minimizing changes to the WARs' POMs
Note: I'm familiar with WARs, tomcat and servlets, but not so much with EARs.
Thanks in advance.
Hmmm... Most Java EE containers use isolated classloaders for WARs, even in an EAR (even if the Java EE spec does not mandate class loading isolation among modules of a single EAR) so I wouldn't expect to much from an EAR packaging, especially if you want your application to remain portable (i.e. if you don't want to rely on any app server specific behavior).
Now, if really it makes sense to share your session factory and your 2nd level cache between several applications, maybe consider merging them in a single WAR. That would be the easiest way IMO. But I'd be tempted to ask why are they separate then? When applications are separate, they have most of time separate governance and I don't know if deploying them together would be a good idea in such case.
And if merging the WARs is not an option, please tell us which container you are using.
Have you considered making use of a coherent clustered L2 cache? If you're using multiple app servers you might see more benefit then as they would all be sharing the same coherent cache
Using a shared parent application context in a multi-war spring application
http://blog.springsource.org/2007/06/11/using-a-shared-parent-application-context-in-a-multi-war-spring-application/
I've been looking into OSGi recently and think it looks like a really good idea for modular Java apps.
However, I was wondering how OSGi would work in a web application, where you don't just have code to worry about - also HTML, images, CSS, that sort of thing.
At work we're building an application which has multiple 'tabs', each tab being one part of the app. I think this could really benefit from taking an OSGi approach - however I'm really not sure what would be the best way to handle all the usual web app resources.
I'm not sure whether it makes any difference, but we're using JSF and IceFaces (which adds another layer of problems because you have navigation rules and you have to specify all faces config files in your web.xml... doh!)
Edit: according to this thread, faces-config.xml files can be loaded up from JAR files - so it is actually possible to have multiple faces-config.xml files included without modifying web.xml, provided you split up into JAR files.
Any suggestions would be greatly appreciated :-)
You are very right in thinking there are synergies here, we have a modular web app where the app itself is assembled automatically from independent components (OSGi bundles) where each bundle contributes its own pages, resources, css and optionally javascript.
We don't use JSF (Spring MVC here) so I can't comment on the added complexity of that framework in an OSGi context.
Most frameworks or approaches out there still adhere to the "old" way of thinking: one WAR file representing your webapp and then many OSGi bundles and services but almost none concern themselves with the modularisation of the GUI itself.
Prerequisites for a Design
With OSGi the first question to solve is: what is your deployment scenario and who is the primary container? What I mean is that you can deploy your application on an OSGi runtime and use its infrastructure for everything. Alternatively, you can embed an OSGi runtime in a traditional app server and then you will need to re-use some infrastructure, specifically you want to use the AppServer's servlet engine.
Our design is currently based on OSGi as the container and we use the HTTPService offered by OSGi as our servlet container. We are looking into providing some sort of transparent bridge between an external servlet container and the OSGi HTTPService but that work is ongoing.
Architectural Sketch of a Spring MVC + OSGi modular webapp
So the goal is not to just serve a web application over OSGi but to also apply OSGi's component model to the web UI itself, to make it composable, re-usable, dynamic.
These are the components in the system:
1 central bundle that takes care of bridging Spring MVC with OSGi, specifically it uses code by Bernd Kolb to allow you to register the Spring DispatcherServlet with OSGi as a servlet.
1 custom URL Mapper that is injected into the DispatcherServlet and that provides the mapping of incoming HTTP requests to the correct controller.
1 central Sitemesh based decorator JSP that defines the global layout of the site, as well as the central CSS and Javascript libraries that we want to offer as defaults.
Each bundle that wants to contribute pages to our web UI has to publish 1 or more Controllers as OSGi Services and make sure to register its own servlet and its own resources (CSS, JSP, images, etc) with the OSGi HTTPService. The registering is done with the HTTPService and the key methods are:
httpService.registerResources()
and
httpService.registerServlet()
When a web ui contributing bundle activates and publishes its controllers, they are automatically picked up by our central web ui bundle and the aforementioned custom URL Mapper gathers these Controller services and keeps an up to date map of URLs to Controller instances.
Then when an HTTP request comes in for a certain URL, it finds the associated controller and dispatches the request there.
The Controller does its business and then returns any data that should be rendered and the name of the view (a JSP in our case). This JSP is located in the Controller's bundle and can be accessed and rendered by the central web ui bundle exactly because we went and registered the resource location with the HTTPService. Our central view resolver then merges this JSP with our central Sitemesh decorator and spits out the resulting HTML to the client.
In know this is rather high level but without providing the complete implementation it's hard to fully explain.
Our key learning point for this was to look at what Bernd Kolb did with his example JPetstore conversion to OSGi and to use that information to design our own architecture.
IMHO there is currently way too much hype and focus on getting OSGi somehow embedded in traditional Java EE based apps and very little thought being put into actually making use of OSGi idioms and its excellent component model to really allow the design of componentized web applications.
Check out SpringSource dm Server - an application server built entirely in terms of OSGi and supporting modular web applications. It is available in free, open source, and commercial versions.
You can start by deploying a standard WAR file and then gradually break your application into OSGi modules, or 'bundles' in OSGi-speak. As you might expect of SpringSource, the server has excellent support for the Spring framework and related Spring portfolio products.
Disclaimer: I work on this product.
Be aware of the Spring DM server licensing.
We've been using Restlet with OSGi to good effect with an embedded Http service (under the covers it's actually Jetty, but tomcat is available too).
Restlet has zero to minimal XML configuration needs, and any configuration we do is in the BundleActivator (registering new services).
When building up the page, we just process the relevant service implementations to generate the output, decorator style. New bundles getting plugged in will add new page decorations/widgets the next time its rendered.
REST gives us nice clean and meaningful URLs, multiple representations of the same data, and seems an extensible metaphor (few verbs, many nouns).
A bonus feature for us was the extensive support for caching, specifically the ETag.
SpringSource seems to be working on an interesting modular web framework built on top of OSGi called SpringSource Slices. More information can be found in the following blog posts:
Modular Web Applications with SpringSource Slices
Pluggable styling with SpringSource Slices
Slices Menu Bar Screencast
Have a look at RAP! http://www.eclipse.org/rap/
Take a look at http://www.ztemplates.org which is simple and easy to learn. This one allows you to put all related templates, javascript and css into one jar and use it transparently. Means you even have not to care about declaring the needed javascript in your page when using a provided component, as the framework does it for you.
Interesting set of posts. I have a web application which is customized on a per customer basis. Each customer gets a core set of components and additional components depending on what they have signed up for. For each release we have to 'assemble' the correct set of services and apply the correct menu config (we use struts menu) based on the customer, which is tedious to say the least. Basically its the same code base but we simply customize navigation to expose or hide certain pages. This is obviously not ideal and we would like to leverage OSGi to componentize services. While I can see how this is done for service APIs and sort of understand how resources like CSS and java script and controllers (we use Spring MVC) could also be bundled, how would you go about dealing with 'cross cutting' concerns like page navigation and general work flow especially in the scenario where you want to dynamically deploy a new service and need to add navigation to that service. There may also be other 'cross cutting' concerns like services that span other of other services.
Thanks,
Declan.