I am using third party framework and our application and that framework both are having same logger slf4j. I have deployed my application on Tomcat and IBM WAS. Now I am seeing few severe exceptions from that framework, which I want to hide, and only want to see the logs of my application. Please suggest, how we could achieve it.
Related
Instead of using maven goal "gcloud:run" I use "dev_appserver.py" to run my web app.
The app is an ordinary web app using Flexible Environment, Java 8, Jetty 9 in compatibility mode with Google App Engine. It uses a appengine-web.xml to specify a logging.properties file which is set to .level=FINE
How do I specify logging? Neither java.util.Logger or System.out.println seems to output anything in the console.
It all relies on Jetty and configuring to log. I made a solution with SLF4J. All needed is adding it as dependency.
Read more here http://aimmoth.blogspot.se/2016/06/logging-with-flexible-environment-and.html
I have tried several logging frameworks (log4j / slf4j with logback/ commons-logging) on websphere to redirect each application log on a separate file, without any sucess.
If i have two applications deployed on same JVM: I am not able to know related errors of each application: All non catched exceptions gets redirected to SystemOut.log file, instead of getting redirected to the appropriate application log file.
Is there any way to achieve that on websphere ?
It would be useful if you post the configuration files you've tried for each logging framework, and provide more details of each scenario. I have used log4j and logback with WebSphere and never ran into problems like yours.
Working on a project that runs an embedded Jetty web server withing its infrastructure. We are looking at addings a new web application that would benefit greatly from allowing views to be plugged in using OSGi. Vaadin is our web framework of choice.
There is a great tutorial on creating an OSGi pluggable Vaadin application in GlassFish where the web container and OSGi container are bridged. That is, the web container is not running in the OSGi container. Here is the tutorial: https://vaadin.com/wiki/-/wiki/Main/Creating%20a%20Modular%20Vaadin%20Application%20with%20OSGi
My question is. Would it be possible to bridge an embedded Jetty web container and OSGi container in the same way as described in this tutorial.
Running jetty in an OSGi container is simply not an option for us as we have to work with existing deployment.
You should be able to embed any 4.2 compliant framework via the org.osgi.framework.launch.FrameworkFactory class. There's a few good examples if you google, two good ones are on the Felix site, and Neil Barlett's blog.
Configuring it will be far more work - you'll need to export all the Jetty and servlet packages via a system property org.osgi.framework.system.packages.extra and use something like Felix fileinstall or a console and pax-url to un/deploy bundles.
While your Vaadin app will be dynamic - nothing from Jetty or the embedding application will be (i.e. domain entities, services etc).
Could you embed a different container? Eclipse Virgo and JBoss AS are both OSGi and J2EE containers.
http://www.eclipse.org/virgo/
http://www.jboss.org/as7
I have been looking for a solution to create a modular web application, which is modular in the sense that user can provide its own plugin in form of a simple jar which will then provide its own data to my web application and my webapp will be responsible for displaying it.
Now the catch is i want my web app to be as generic as possible without relying on the j2ee web container to support anything . i.e. i cant rely on my web container to provide osgi support and deploy web application as an osgi bundle itself ( which truly makes things very simple for eg. glassfish and WAS).
I am planning to use equinox and only solution i see currently is the servlet bridge they provide on their official site, but to me it is really a pain to delegate everything to a servlet which will in turn interpret the request and find an apropriate bundle Class and then again communicate back somehow only the data to the web application.
To me it would be wonderful if my web app was also a bundle.
Is there anything close to this ideal solution which i can try for? Or any other communication method between the two relams of osgi and web appliction (container)?
The OSGi spec details the WAB (Web Archive Bundle) format.
And Pax Web offers great support for WAB/WAR webapps (PAX Web runs fine on Equinox, Felix, etc)
Using pax web you get the BundleContext via the ServletContext, eg:
BundleContext bundleContext = (BundleContext) getServletContext().getAttribute("osgi-bundlecontext");
For the user driven pluggability you mention, I'd suggested you provide some service interfaces for the plugin bundles to implement and in your webapp use a ServiceTracker to listen for their registration (unless you're using Declarative Services). You also easily be able to install bundles from an upload servlet.
I'm guessing users uploading plugins would have to be logged in and authorized, so security issues will have been met at this point.
EDIT: replying to comment here as not enough space in comment field
Apologies, think I misinterpreted you question - you have an existing webapp container(s) and you want to deploy a WAR with OSGi functionality? If that's the case then either use the ServletBridge as others have mentioned or embed an OSGi framework into your WAR (this is relatively easy, see this for example).
You could even make this optional by attempting to get the BundleContext from the ServletContext and if this returns null then launch your own embedded framework. That way it'll run in a native OSGi container (e.g. Glassfish) or in a Java EE app server.
Otherwise, PaxWeb is an implementation of the HttpService and WebApp OSGi specs, but with lots of extensions to make life easier - but you deploy this to an OSGi container.
You might want to look into Apache Sling. It is a web framework that has an embedded OSGi container. The OSGi container is called Apache Felix and is pretty good.
ServletBridge is for embedding an OSGI contianer within a web container. The other option is to embed a web container (as a bundle) in an OSGI container. The following article has some details on how to achieve this.
http://java.dzone.com/articles/osgi-and-embedded-jetty
You may want to try ChonCMS - http://www.choncms.com
Its architecture is based exactly on what you are asking, it comes with few plugins to enable base CMS functionality, it is modular platform with minor web app container using felix and plugins can be added/removed at run time as well.
Disadvantage might be that it has lack of documentation, but you may ask, it is open source, I'm sure they will be happy to answer questions, and even better you can contribute - it is still in incubation phase.
I have a quite ordinary web application which logs with slf4j, which is fine, and I have used several slf4j backends without any problems.
Under Tomcat I just told logback to point at a location in the filesystem and log there, but now I want to deploy several independent instances of this application each in its own domain in a single Glassfish 3.0.1 instance, and I have now found that I would like my slf4j logging to work well with Glassfish.
What would be a good way (dare I say "best") to have my logging taken care of by Glassfish. Should I just flatten my logs to System.out with logback and let Glassfish handle the console output, or is there a better, standard way to reach the loggers inside Glassfish?
EDIT: Investigation has shown that GlassFish 3.0.1 does not provide neither the SLF4J API or a binding in the classes visible to a JSP-page with default configuration.
By providing slf4j-api-X.jar and slf4j-jdk14-X.jar the slf4j-logging events are forwarded to java.util.logging which is captured properly by Glassfish (see http://docs.sun.com/app/docs/doc/820-7692/abluj?l=en&a=view for details).
Investigation has shown that GlassFish 3.0.1 does not provide neither the SLF4J API or a binding in the classes visible to a JSP-page with default configuration.
By providing slf4j-api-X.jar and slf4j-jdk14-X.jar the slf4j-logging events are forwarded to java.util.logging which is captured properly by Glassfish (see http://docs.sun.com/app/docs/doc/820-7692/abluj?l=en&a=view for details).
Note: Glassfish logging does not capture stack traces.