This is part 9 of my blogseries about ‘Logging in OSGI Enterprise Applications‘ – you’ll find all parts here.
Following this blog series you should be able to integrate most other projects into your logging environment without any problems.
But as always: sometimes you have to know something more 😉
Here are only some hints if you’re integrating Riena, redView or if you wanto to log from your oAW workflows.
Logging with Riena
Riena is part of Eclipse Runtime (RT) projects and I’m using different parts of Riena in my OSGI Equinox Enterprise Server and RCP Runtime. (Riena Lnf, Riena UI and Navigation, Riena Remote Services, Riena Object Transactions) If you add Riena to your projects, you can install
- Riena SDK
- Riena Examples.
Normaly Riena is only installed into your Target Platform – you should install Riena SDK and Examples normaly only there and not into the IDE.
In my projects I’m using some bundles of Riena also inside the IDE because redView designer Editor has dependencies to Riena – so I have to install Riena SDK (but not the examples !) also into the running Eclipse IDE.
Riena uses Equinox Extended Log Services, so you have to catch OSGI Log Services if you want to integrate Riena log messages. See Part 6 of this blog series where I described how to start Logging in Runtime Projects and to catch OSGI Log Services using Equinox DS (Declarative Services). Riena also has a special “Developer mode for logging” using a System Property:
-Driena.development=false
You should set it to false if you catch all Log Events by yourself – otherwise there will be unwanted or duplicated log outputs.
If you don’t catch OSGI Log Services, then you can set riena.development=true and get debug informations to the system.out/err. More about Riena System Properties here.
Here’s a Log Event…
- … originally logged from Riena using Equinox Extended OSGI Log Services (because Equinox ExtendedLogService contains a LoggerName: HessianRemoteServicePublisher in this case)
- the LogEntry was received using a LogListener, which was added by DeclarativeServices Component in bundle org.ekkescorner.logging.starter.runtime (see part 5 of this blog series)
- the catched LogEntry was logged to Logback using Lilith ClassicMultiplexSocketAppender
- finally the LogEntry can be viewed using Lilith. (see part 8 of this blog series) Because our LogListener annoteded the Log Entry with SLF4J Marker’s we’re able to get the producing Bundle Name (org.eclipse.riena.core in this case)
Logging with redView
redView (Riena EMF Dynamic Views for Business Applications) will be published open source this autumn and contains:
- redView Designer: aWYSIWYG Eclipse Editor to view and design (Riena) SWT Views with an underlying EMF model
- redView Runtime: dynamic rendered components: SWT Widgets, Riena Ridgets, nebula Widgets
redView is using SLF4J as Logging API and is optimized for a Logback implementation, but of course you can use redView with your choice of Logging Framework – then you only must provide a SLF4J implementation, which is possible using Log4J, Apache commons logging, PAX Logging and more. (see here and here)
If you decide also to use Logback as your SLF4J implementation and you need logging output from redView, then you have to install:
- … into your ide (only if you need logging from redView’s WYSIWYG editor)
- logback core bundles
- logback ide bundles
- logback dependency bundles
- … into your target platform
- logback core bundles
- logback runtime bundles
- logback dependency bundles
all bundles will be available to download at the end of this blog series.
Logging with openArchitectureWare (oAW)
oAW is a combination of some other projects from Eclipse Modeling and since Galileo part of Eclipse Release train. oAW means: MWE (Eclipse Modeling / EMFT), Xpand/Xtend (Eclipse Modeling / M2T)and Xtext (Eclipse Modeling / TMF)
Running an oAW workflow it’s a good idea to use logging, but at the moment you cannot catch all logging messages under one umbrella, because
- MWE
- is hard wired to org.apache.commons.logging using Require-Bundle dependency
- see Bugzilla 284715 to use Import-Package dependency (already fixed in HEAD 🙂
- Xpand and Xtend
- are also hard wired to org.apache.commons.logging using Require-Bundle dependency
- see Bugzilla 284714 to use Import-Package dependency (already fixed in HEAD 🙂
- Xtext
- is hard wired to org.eclipse.xtext.log4j which itself exports the log4j packages
- see Bugzilla 284716 to use Import-Package dependency
I’ll blog about oAW workflow logging again as soon as these bugs are fixed to demonstrate the correct configuration to get it all under SLF4J / Logback.
you’ll find the overview of this blog series here. stay tuned… part 10 follows…
mobile && more 