Do some implemented OSGi frameworks allow me to bundle css styles and javascript as well?
Or i have to use other approaches to do this?
One way is to create a WAB (Web Application Bundle), it's a war with OSGi manifest which needs a Web-ContextPath attribute, this doesn't necessarily be a war it may also be a jar with a war like structure.
Might want to take a look at the Pax Web Framework (or Karaf wich uses it).
The Pax Web framework provides all that is needed to deploy Servlets/JSPs resources etc. also in a OSGi manner. Yes also as Services via a Whiteboard approach. Another point is Servlet 3 and CDI, all of this is also supported by Pax Web (for CDI you'll also need Pax CDI)
Best take a look at the various samples and the integration tests.
You can have any resource in a jar. This is not the question of OSGi framework, but the question of the technology you would like to use. How will it find the resource in your jar.
E.g.: If you create a WAB, that behaves similar to a WAR.
Although WABs can be used with several OSGi based web server, I personally do not like them as they are monoholitic. There are alternatives to provide resources:
https://github.com/bndtools/aQute/tree/master/aQute.webserver
An implementation by Peter Kriens that allows us to download any files that are placed into the /static/ folder of any bundle. The Servlet is registered on the /static/ path so if you have a file in your bundle at /static/css/mystyle.css, you can access it via http://foo.com/static/css/mystyle.css
https://github.com/everit-org/webresource
Similar solution but this is based on bundle capabilities. The first release is expected in the end of October 2014, but the important logic is already implemented. This library needs OSGi 6.0 and Java 8 since the latest commit that might be a limitation for a while.
JSPs are other question. If you use a WAB and an embedded Servlet container with JSP support, they should work. You can also register the JSP servlet manually into your OSGi container based on the technology you use (e.g.: with whiteboard pattern).
Amdatu has support for this in the Web Resources component. You simply add your static resources to the bundle using the -Include-Resource bnd header and add a few manifest headers to serve the files directly.
An example of this could be the following. This example can be found in the Amdatu Chat example.
Include-Resource: \
app=dist/app
X-Web-Resource-Default-Page: index.html
X-Web-Resource-Version: 1.1
X-Web-Resource: /chat;app
Related
I have recently started on Java EE and having a tough time understanding it. I have read some answers here on SO but I still feel like there are some gaps in my understading. Basically, Java EE is a specification and application servers like TOMCAT, Glassfish etc., have the concrete implementations. Also, anyone can provide implementation for EE.
So, I have downloaded javax.sevlet-api-4.0.1-sources.jar from Maven repo and I can see that they are just Interfaces and I assume we just use them to build the project?
In tomcat lib folder there is a servlet-api.jar. is this the tomcat implementation of Servlet? and if it is, then is it possible to replace it with another servlet version implementation?
Now, Hibernate is the implementation of Persistence API. if i want to use Hibernate with Tomcat. I just need to add the Hibernate related jars to my application and can use them for both build and run? without actually getting the contract classes.
You need the servlet-api jar file when compiling your code, because that's where e.g. HttpServletRequest is. You don't need to include that jar with your application, because it is provided already by the Servlet Container you deploy your war file to, e.g. Tomcat.
With Tomcat, the implementation of the various servlet classes are in catalina.jar, at least for Tomcat 9, e.g. ApplicationHttpRequest is the class implementing HttpServletRequest. You don't need this to compile your code.
To be accurate, Tomcat is not a fully fledged JavaEE container, it only handles part of the JavaEE spec (mainly servlet, jsp, jndi and a few others).
And as Andreas wrote you need serlvet-api.jar to compile your code (otherwise HttpSerlvetRequest will miss), but as tomcat already provides it (as an interface) as well as an actual implementation, you should add it as a "provided" dependency in your maven file.
I want to add pluggable jar i.e. the jar with web-fragment.xml after server is up-and-running. and perform the scanning of this jar and initialize servlet components defined in web-fragment.xml of newly added jar.
If this is not possible please explain the reason.
Each Java EE application is atomic. It is deployed and undeployed entirely. You can't change application without redeploy. So it is not possible.
Correct solution is differ. You should deploy independent application and provide pluggable interfaces between main application and such plugins. Technical details are depends from situation. E.g. JSF has resource-handler. You can write special class (need be registered in faces-config.xml) for loading JSF pages from nonstandard place.
Can i Have a single application with more than one web.xml files? And can two applications have a parent child relationship so that there are two web.xml?
For below servlet 3.0 you cannot.
If you are using 3.0 there is a possibility.
In JSR 315: Java Servlet 3.0 Specification, web-fragment.xml is introduced for pluggability of library jars which are packaged under WEB-INF/lib. The content of web.xml and web-fragment.xml are almost the same. One can define servlets, filters and listeners there. One can also specify metadata-complete=true in a given web-fragment.xml. In the latter case, the annotation processing of classes in that jar would be skipped. With web-fragment.xml, library jars can be self-contained and provide web related metadata information.
For sure, having two xml creates confusion and besides all, If you explain whats your exact requirement, you'l get a good/standard solution for your problem.
Can i Have a single application with more than one web.xml files?
It depends on the approach.
Approach 1
If you are working in an environment where there are certain servlets (I remember I worked on an old project where there was a Minification servlet and its purpose was to minify the JS/CSS at deploy time) and settings like e.g certain user-contraints and realms that you don't want configured on your development environment since you will be working with exploded JS/CSS and you want to bypass basic secuirty constraints configured in the application just for ease of development but you want them all tested out on QA , so it "sort of" of makes sense to have 2 different deployment descriptors configured for the same application. One in which you have only the basic settings to just deploy the application for development and on the other you have all your production settings that you want tested out on QA from A to Z.
But again, I want to make it clear that you can deploy you application using only ONE deployment descriptor.
Approach 2
Lets say you want your deployment descriptor to be broken down into small parts for plugg-ability purpose like you define your Servlets in one file and you define your securutiy constraints in other file. These files or web-fragments.xml can only work with Servlet3.0. If you look closely to how these fragments are used, at deploy time all these fragments are merged and read by the container as a "single" file (the deployment descriptor).
So in the end , we again wind up with a SINGLE deployment descriptor for the application.
We often have Custom Mediators (Java classes) that are performing transformations or other things. Each time we want to change only one little thing inside the class, we need to restart the whole WSO2 ESB.
May the "custom mediator" approach is wrong, but we'd like to keep the java classes, but de-coupled from the whole server - like proxies or endpoints. (Our classes are inside a .jar in /components/lib)
How can a custom mediator or java class added to the WSO2 ESB without restarting?
<class name="my.domain.MyJavaClassThatMustBeUpdatedWithoutRestart"/>
You can create an osgi bundle from your class and then you can control the classes behavior from the OSGI Console. You need to start esb with -DosgiConsole option. You can find more information from this blog post.
http://lalajisureshika.blogspot.co.uk/2013/03/some-useful-osgi-commands-to-find.html
While starting up we make OSGI bundles out of the non-OSGI jars in components/libs.
So you must restart if you want to change the custom mediator jars.
As per the below coment explaining the answer,
WSO2 Products are running on an OSGI based platform. So if you change an OSGI bundle you can restart the bundle from the OSGI Console without restarting the whole server. Also the OSGI Container used by WSO2 is Eclipse Equinox OSGI Container. It provides the ability to add non-OSGI jars to product with the feature of, converting those jars in to OSGI Bundles. And that feature works only at the server startup. So if you want to add/change those jars you should restart the server. In runtime you can change OSGI bundles, but you can not convert non-OSGI bundeles to OSGI in runtime.
We are considering to use Configuration Admin Service as a primary API for configuring components in our OSGi-based application. It would be nice if we could reuse some existing implementation so I'm trying to investigate and evaluate the most popular ones. I know there is:
Apache Felix Config Admin (org.apache.felix.cm)
Equinox Config Admin (org.eclipse.equinox.cm)
Are there any other implementations to be considered?
Also I was not able to find any good documentation for these implementations. I would be mainly interested in the implementation-specific details. For example I was wondering how different implementations persist the configuration data (e.g. multiple property files? XML file? multiple XML files? database?, ...).
Felix's Configuration Admin has a default implementation that persists to the file system, but they define a service interface (org.apache.felix.cm.PersistenceManager) for alternative backends that you could plug in instead.
The default implementation does the following:
The FilePersistenceManager class stores configuration data in
properties-like files inside a given directory. All configuration files are
located in the same directory.
Configuration files are created in the configuration directory by appending
the extension ".config" to the PID of the configuration. The PID
is converted into a relative path name by replacing enclosed dots to slashes.
Non-symbolic-name characters in the PID are encoded with their
Unicode character code in hexadecimal.
The three public implementations I know of are
Apache Felix
Equinox …source (this has moved recently)
Knopflerfish …front page and …source
Equinox's implementation of the ConfigurationAdmin service appears not to support fine control over the persistence policy, as Felix's does, and the Knopflerfish implementation looks (I've only read the source briefly) similar to Equinox's.
The Felix one appears to be the most recently updated and the most reliable.
At present these are the only ones I can find; at dm Server we made the decision to use Felix's bundle, and this is now obtainable from the SpringSource Enterprise Bundle Repository, where you can quick-search for Apache Felix or ConfigAdmin.
Just to complete the answer further: I personally also prefer the Felix implementation. For an example of how to change the way storage occurs at the back-end using a PersistenceManager, see also this implementation that uses standard Java property files as backing storage. Has some limitations, but at least allows you to store your configuration with your application and apart from your OSGi framework implementation.