How do LogService and LogReaderService in Equinox work along? - eclipse

I'm developing a OSGi Equinox bundle and I'd like to add some logging to it, mostly to be redirected to the OSGi console, just for debugging purposes.
After discarding the usage of log4j, since there are a couple of logging services in Equinox (LogService and ExtendedLogService), I found this article describing how to use the LogService:
OSGi Log Service
So I came up with an Activator that looks like this:
package org.example.servlet;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
import org.osgi.framework.ServiceReference;
import org.osgi.service.log.LogService;
import org.osgi.util.tracker.ServiceTracker;
import org.eclipse.equinox.log.ExtendedLogService;
public class Activator implements BundleActivator {
private static BundleContext context;
private ServiceTracker logServiceTracker;
private LogService logService;
static BundleContext getContext() {
return context;
}
/*
* (non-Javadoc)
* #see org.osgi.framework.BundleActivator#start(org.osgi.framework.BundleContext)
*/
public void start(BundleContext bundleContext) throws Exception {
Activator.context = bundleContext;
// create a tracker and track the log service
logServiceTracker = new ServiceTracker(context, LogService.class.getName(), null);
logServiceTracker.open();
// grab the service
logService = (LogService) logServiceTracker.getService();
if(logService != null)
logService.log(LogService.LOG_INFO, "Yee ha, I'm logging!");
}
/*
* (non-Javadoc)
* #see org.osgi.framework.BundleActivator#stop(org.osgi.framework.BundleContext)
*/
public void stop(BundleContext bundleContext) throws Exception {
Activator.context = null;
}
Well, I never see the logged message in the OSGi console...looking for some more info, I found this thread:
How to use Equiniox's LogService ?
Some answers suggest that I should implement a LogServiceReader object that actually listens for logging events and (this is just my guess), redirects logged messages to whatever (file, console, etc...)
Now my question, more than how to implement this interface, is how do I do the binding between my implementation of the LogServiceReader and the LogService used in the Activator...
Thanks!
Alex

To answer the question directly:
A LogService is a service responsible for storing log messages.
A LogReaderService is a service responsible for reading these log messages and dispatching them to log listeners.
The binding between these is done automatically.
What you will do yourself is log messages to the LogService on the one side, and possibly bind LogListeners to the LogReaderService, that will write out the logs somewhere, for example the console, on the other side.
To solve your problem of the logs not appearing, you need to do a few additional things.
First of all, did you install a bundle offering an implementation of the LogService and the LogReaderService into your osgi container?
You can check for the presense of an org.osgi.service.log.LogService by adding something like this to your Activator:
if(logService != null){
System.out.println("There is a LogService available");
logService.log(LogService.LOG_INFO, "Yee ha, I'm logging!");
}
else {
System.out.println("There is no LogService available");
}
Or just type "bundles" in the equinox console and look for a bundle offering an org.osgi.service.log.LogService and an org.osgi.service.log.LogReaderService.
If no LogService is available, install one. For example:
install http://oscar-osgi.sf.net/repo/log/log.jar
The org.apache.log4j equinox dependency offers such a service too.
Start and stop your own bundle again. It should now print "There is a LogService available".
Now your messages are logged to the LogService and processed by the LogReaderService, but still, since there might be no LogListeners registered with this service(depending on other bundles started),
You might need to have to add a LogListener yourself in your bundle Activator.
For an example bundle Activator who does this, check http://blog.kornr.net/index.php/2008/12/09/understanding-the-osgi-logging-service.

Well, just in case someone else is interested in the subject. I found a really nice wiki in Google Code explaining how OSGi logging system works that is a 'must read':
Understanding OSGi Logging
Since I only want to use a log to print in console, the solution proposed there works for me. Only problem was finding an implementation of the LogService that worked as expected. The one pointed out in the article actually works, but implements version 1.1 while what current LogService specification is at version 1.3 as far as I know. So what I did was, downloaded the sources from the previous implementation and adapted that implementation to my taste and to latest version (1.3) specification. You can find sources here.
Obviously, you can also use yours or any others implementation of the LogService interfaces, up to you.
Besides, if you plan to use a back-end existing logging service, such as commons-logging, or sl4j, etc...I recommend these links, they provide great info about where to start:
Building backend
OSGi logging overview
This was overkill for me, since all I wanted was a way to print messages in the OSGi console, but without having to use log4j, fragments and the like.
Hope somebody found this useful
Regards,
Alex

Related

VaadinServiceInitListener not picked up in a Quarkus app

I have a Quarkus application using current versions of Vaadin Flow and Quarkus (23.2.4 and 2.13.1.Final). I want to have a VaadinServiceInitListener to check access annotations on the views (#RolesAllowed(...)) using AccessAnnotationChecker. I believe annotating the implementation with #VaadinServiceEnabled
should fix this, but I need to register it in META-INF/services/com.vaadin.flow.server.VaadinServiceInitListener to have it activated. This is how to do it when not using a dependency injection framework. Then everything works as expected and I can use AccessAnnotationChecker to see if the user has access to that view, on BeforeEnterEvent.
I also notice the message Can't find any #VaadinServiceScoped bean implementing 'I18NProvider'. Cannot use CDI beans for I18N, falling back to the default behavior. on startup. Strangely, implementing I18NProvided in a class and annotating it with #VaadinServiceEnabled and #VaadinServiceScoped makes that message go away, eg. it is recognized by CDI.
Why isn't my VaadinServiceInitListener implementation recogized? Currently it is annotated with
#VaadinServiceEnabled
#VaadinServiceScoped
#Unremovable
My pom.xml include
vaadin-quarkus-extension,
quarkus-oidc,
quarkus-keycloak-authorization,
vaadin-jandex
Instead of using a listener, you can use a CDI event.
Quarkus's dependency injection solution is based on CDI, so you can use the same events. Here's an example
public class BootstrapCustomizer {
private void onServiceInit(#Observes
ServiceInitEvent serviceInitEvent) {
serviceInitEvent.addIndexHtmlRequestListener(
this::modifyBootstrapPage);
}
private void modifyBootstrapPage(
IndexHtmlResponse response) {
response.getDocument().body().append(
"<p>By CDI add-on</p>");
}
}
More information here https://vaadin.com/docs/latest/integrations/cdi/events

No event context active - RESTeasy, Seam

I'm trying to add a RESTful web service with RESTeasy to our application running on JBoss 7.x, using Seam2.
I wanted to use as little Seam as possible, but I need it for Dependancy Injection.
My REST endpoints are as follows:
#Name("myEndpoint")
#Stateless
#Path("/path")
#Produces(MediaType.APPLICATION_JSON+"; charset=UTF-8")
public class MyEndpoint {
#In private FooService fooService;
#GET
#Path("/foo/{bar}")
public Response foobar(#CookieParam("sessionId") String sessionId,
#PathParam("bar") String bar)
{ ... }
}
I'm using a class extending Application. There is no XML config.
I can use the web service methods and they work, but I always get an IllegalStateException:
Exception processing transaction Synchronization after completion: java.lang.IllegalStateException: No event context active
Complete StackTrace
I did try everything in the documentation, but I can't get it away. If I leave out the #Stateless annotation, I don't get any Injection done. Adding #Scope doesn't do jack. Accessing the service via seam/resource/ doesn't even work (even without the Application class with #ApplicationPath).
It goes away if I don't use Dep. Injection, but instead add to each and every method
fooService = Component.getInstance("fooService");
Lifecycle.beginCall();
...
Lifecycle.endCall();
which isn't really a good solution. Nah, doesn't work either...
I have resolved the issue. For some reason (still not sure why, maybe because I tried to use Annotations and code exclusivly and no XML config), my REST service was availiable under a "non-standard" URL.
Usually it'd be something like "/seam/resources/rest".
Anyway, if you have a "custom" path, Seam doesn't know it should inject a context. You need to add <web:context-filter url-pattern="something" /> to your component.xml.
Specifically we already had this tag, but with the attribute regex-url-pattern and I extended it to match the REST URL.

osgi dependency injection between services

I just started playing around with OSGi services and have the following situation. I have a project which contains 2 services. Service A requires Service B, so I tried to inject the dependent service using
#Inject
private ServiceB svc;
but the framework wont inject. If I setup the following two methods in Service A
and set these methods as "bind / undbind" in my OSGi componentA.xml the framework calls
these methods and I can use Service B in Service A.
public synchronized void bind(IServiceB service)
{
this.svc = service;
}
public synchronized void unbind(IServiceB service)
{
if (this.svc == service)
{
this.svc = null;
}
}
The question is, why does it not work with #Inject ? Sorry if this is a stupid question, I'm quite new to this whole topic. Many thanks in advance!
It looks like you are using Declarative Services, which does not support field injection or the JSR-330 annotations. Field injection has limited utility in OSGi, where services may be injected or "un-injected" at any time. Method injection is more generally useful because it gives you an opportunity to do something when this happens.
However I do urge you to use the annotations for Declarative Services. This will save you from having to write the component.xml by hand.

GWT development mode is quiet

I'm developing a project with GWT for quite some months but since two weeks or so i get no more feedback in the jetty development mode window when an error occures...
How could that come?? Could it be caused by some missconfiguration of the logging module? Some errors appear on the console of the started jetty application as [INFO].
Try CCleaner Software and clean all Recent files, browser Cache, Temporary files etc. Then just restart eclipse or better restart the entire System. Also, check if you have GWT.log("MESSAGE") method called for Errors/Exceptions.
The strange behaviour with GWT can happen if:
You have "server" (not included source code) class
You have only import to server class
One of your bean used to communication by service is not serializable (or not extends IsSerializable) or any of it attributes is not serializable
Your bean used to communication by service do not have not parameters constructor (or any of parent class)
Your bean used to communication by service has final field
I had almost all from this when I searched why my code is broken. I did not included all cases of course :)
Update
In our project we extends AsyncCallback
public abstract class MyAsyncCallback<T> implements AsyncCallback<T> {
#Override
public final void onFailure(Throwable caught) {
yourLogger.log(caught);
onFailureDefault(caught);
}
protected abstract void onFailureImpl(Throwable caught);
}
You has to replace all your AsyncCallback with this. Now you have control on errors. Sometimes there are suppressed by wrong error handling.
See also GWT.setUncaughtExceptionHandler(GWT.UncaughtExceptionHandler handler)

How to use OSGi getServiceReference() right

I am new to OSGi and came across several examples about OSGi services.
For example:
import org.osgi.framework.*;
import org.osgi.service.log.*;
public class MyActivator implements BundleActivator {
public void start(BundleContext context) throws Exception {
ServiceReference logRef =
context.getServiceReference(LogService.class.getName());
}
}
My question is, why do you use
getServiceReference(LogService.class.getName())
instead of
getServiceReference("LogService")
If you use LogService.class.getName() you have to import the Interface. This also means that you have to import the package org.osgi.services.log in your MANIFEST.MF.
Isn't that completely counterproductive if you want to reduce dependencies to push loose coupling? As far as I know one advantage of services is that the service consumer doesn't have to know the service publisher. But if you have to import one specific Interface you clearly have to know who's providing it. By only using a string like "LogService" you would not have to know that the Interface is provided by org.osgi.services.log.LogService.
What am I missing here?
Looks like you've confused implementation and interface
Using the actual interface for the name (and importing the interface , which you'll end up doing anyway) reenforces the interface contract that services are designed around. You don't care about the implemenation of a LogService but you do care about the interface. Every LogService will need to implement the same interface, hence your use of the interface to get the service. For all you know the LogService is really a wrapper around SLF4J provided by some other bundle. All you see is the interface. That's the loose coupling you're looking for. You don't have to ship the interface with every implementation. Leave the interface it's own bundle and have multiple implementations of that interface.
Side note: ServiceTracker is usually easier to use, give it a try!
Added benefits: Using the interface get the class name avoids spelling mistakes, excessive string literals, and makes refactoring much easier.
After you've gotten the ServiceReference, your next couple lines will likely involve this:
Object logSvc = content.getService(logRef)
// What can you do with logSvc now?!? It's an object, mostly useless
// Cast to the interface ... YES! Now you need to import it!
LogSerivce logger = (LogService)logSvc;
logger.log(LogService.LOG_INFO, "Interfaces are a contract between implementation and consumer/user");
If you use the LogService, you're coupled to it anyway. If you write middleware you likely get the name parameterized through some XML file or via an API. And yes, "LogService" will fail terribly, you need to use the fully qualified name: "org.osgi.service.log.LogService". Main reason to use the LogService.class.getName() pattern is to get correct renaming when you refactor your code and minimize spelling errors. The next OSGi API will very likely have:
ServiceReference<S> getServiceReference(Class<S> type)
calls to increase type safety.
Anyway, I would never use these low level API unless you develop middleware. If you actually depend on a concrete class DS is infinitely simpler, and even more when you use it with the bnd annotations (http://enroute.osgi.org/doc/217-ds.html).
#Component
class Xyz implements SomeService {
LogService log;
#Reference
void setLog( LogService log) { this.log = log; }
public void foo() { ... someservice ... }
}
If you develop middleware you get the service classes usually without knowing the actual class, via a string or class object. The OSGi API based on strings is used in those cases because it allows us to be more lazy by not creating a class loader until the last moment in time. I think the biggest mistake we made in OSGi 12 years ago is not to include the DS concepts in the core ... :-(
You cannot use value "LogService"
as a class name to get ServiceReference, because you have to use fully qualified class name
"org.osgi.services.log.LogService".
If you import package this way:
org.osgi.services.log;resolution:=optional
and you use ServiceTracker to track services in BundleActivator.start() method I suggest to use "org.osgi.services.log.LogService" instead of LogService.class.getName() on ServiceTracker initializazion. In this case you'll not get NoClassDefFoundError/ClassNotFountException on bundle start.
As basszero mentioned you should consider to use ServiceTracker. It is fairly easy to use and also supports a much better programming pattern. You must never assume that a ServiceReference you got sometime in the past is still valid. The service the ServiceReference points to might have gone away. The ServiceTracker will automatically notify you when a service is registered or unregistered.