dynamic EMF SWT Views (not only) for Business Applications

…back from the redView – “RoadShow“: Eclipse Democamps in Frankfurt, Vienna (presented by Flo) and Hamburg – also NightSchool at W-JAX and OpenSource Expo in Karlsruhe. This time the Eclipse Democamps were all crowded: the winner was Hamburg with more then 110 attendees.

I like the Eclipse Democamps: see what happens in other projects, always learning something new, interesting discussions… and of course later in the evening meeting friends and drinking some beer. Thanks to all the Organizers, Sponsors and Eclipse Foundation to make these events possible. For me as a self-employed independent Software Architect its an easy way to get in contact with some hundred developers from Eclipse universe living in my country

It was great to demonstrate redView at Democamps and its good to see how many developers are interested to learn more about this project. We’re finishing some final steps to prepare the launch of a first beta of redView this month. Really: otherwise I have to spend a bottle of good redwine to Christian Campo and I would prefer to get one from his wine cellar

redView Slides with audio available

Some asked me to publish my slides from redView – presentation, but these are “Zen“-like, so I added audio and uploaded as movie at Vimeo -

You can watch the slides here.

The slides are only one part of the redView demonstration: there was always also a “live demo” part. So I created some screencasts:

Screencast: First Steps with redView’s WYSIWYG Designer

Click here to view the Screencast at Vimeo.

A simple example about redView Designer Editor, Outline, Properties and how to change design by Drag-n-drop, Properties or from Outline.

The real power behind redView is the combination with openArchitectureWare (Eclipse Modeling: MWE, Xpand/Xtend, Xtext) if you generate your redView Views. Together with Eclipse Runtime (Equinox, Riena) you can even generate a complete Riena RCP Application with UI and Navigation. With redView Eclipse Modeling meets Eclipse Runtime: its a perfect association.

Screencast: Live-Pushing of Design-Changes into running RCP Applications (using CDO)

Click here to view the screencast at Vimeo.

In this screencasts there are two (generated) Riena RCP Applications running: one under OSX, the other one under Linux Ubuntu. Then inside the IDE the UI Designer makes some changes and these are pushed live into the running RCP Applications. This can be very useful while testing new Views together with the business departments. Thanks to CDO the EMF SWT Views are stored on a server anywhere so all can be done a distributed way.

Screencast: redView’s Visibility Processor

Click here to view the screencast at Vimeo.

redView provides Visibility Processor, Visibility Desriptors and Visibility Conflict resolver. This is an example with nested Views to design Associations with Superclasses. Imagine a Driver who drives a Vehicle. Vehicle is an abstract class and this could be a Car or a Truck.

In your SWT View you need the fields of Car or Truck displayed inside a Composite. Imagine how much code this would be and see how easy you define it using redView.

redView at EclipseCon 2010 – redView and e4

Curious to see what will happen at EclipseCon – there are already some discussions how to get redView under Eclipse Umbrella. redView will also be a perfect addition to e4 – we’ll provide next year redView as a ViewPart for e4 workbench.

If you like redView and want to see more, then please comment and vote for my Submissions at EclipseCon 2010:

Dynamic EMF Views (not only) for OSGI Business Applications

- a short Talk (25 Min)

Modeling meets Runtime: In 2 Hours from your Domain Model to a running RCP Application together with UI Designer

I promise: you leave the session with a running RCP Application, the redView UI – WYSIWYG Designer and Views stored on a CDO Server.

BTW: there are also submissions about PDE + Cool Views from Target Platform and Logging in OSGI Applications

[osgi logging] part 6 – how to start the logging framework

This is part 6 of my blogseries about ‘Logging in OSGI Enterprise Applications‘ – you’ll find all parts here.

Normaly you put your needed bundles into the Dropins folder from your IDE (if there’s no update site) or add them to your Target Platform definition and you’re done.

Integrating a Logging Framework there are some requirements:

• you want to get all logged messages from the beginning, so logging bundles have to start early
• you want to control that your bundles are used and not others providing the same packages

You should always carefully think about using Start-Levels, but in this case it makes sense.

If you followed my blog series about Target Platform, then you know that its important to distinguish between IDE and Runtime (Target Platform).

Starting Logging Framework from OSGI Runtime

In most cases you’re interested into the Runtime only, because you want to know what your running product is logging.

Since Galileo you can define the Start-Level in the Product Configuration file:

- same way as from an OSGI Launch Configuration:

or from an Eclipse Application Configuration:

Youl’ll find the setting of Start-Level and Auto-Start under different Tabs and named Plug-Ins or Bundles, but its always the same

Hint: The Auto-Start “default” depends from your setting of “Default Auto-Start” as false or true. If you want to be sure that the right value was choosen you should explicit set to true or false at each bundle.

Here are the settings to autostart the Logging Framework early from your Runtime Product / OSGI Launch / Application Launch:

per ex. Default Auto-Start Level 3

• org.eclipse.osgi: Start-Level -1, Auto-Start true
• org.eclipse.equinox.common: Start-Level 2, Auto-Start true
• org.eclipse.equinox.ds: Start-Level default, Auto-Start true
• all logging framework bundles: Start-Level 2, Auto-Start true
• org.ekkescorner.logging bundles: Start-Level 2, Auto-Start true
• all other bundles: Start-Level default, Auto-Start default

what happens:

1. Start-Level -1: Equinox OSGI Runtime starts at first
2. Start-Level 2: equinox.common and all logging bundles are started
   1. org.ekkescorner.logging.starter.runtime (Bundle-ActivationPolicy: lazy)
      1. Avtivator start() calls SLF4JBridgeHandler.install() – this causes bundle ‘jul.to.slf4j’ to catch all java.util Logging
      2. logs a message: logger.debug(Activator.bundleMarker, “SLF4JBridgeHandler started”) – this causes slf4j and logback to begin initialization, read the config and perhaps log something
3. Start-Level default: all bundles with Auto-Start true are started
   1. org.eclipse.equinox.ds is auto-started
      1. analyzes the DS Component from org.ekkescorner.logging.starter.runtime
      2. if LogReaderServices or ExtendedLogReaderServices become available, our LogListeners will get the LogEntries
   2. other bundles are started if needed and because SLF4J / Logback is initialized all dependencies to logging packages are resolved from SLF4J / Logback and all log messages are catched

Starting Logging Framework from IDE

In some cases you may have the need to log from your running IDE and it should work simply adding some bundles.

Adding bundles to Dropins folder or updating from Update Sites there’s no easy way to set Start-Level or Auto-Start.

Above you have seen how we solve this with the org.ekkescorner.logging.starter.runtime bundle at Runtime

- for the IDE we use another Bundle: org.ekkescorner.logging.starter.ide (Bundle-ActivationPolicy: lazy)

the important part – we have to use the Extension Point org.eclipse.ui.startup to get the bundle early started:

the Class AutoStartLogging has to implement org.eclipse.ui.IStartup

import org.eclipse.ui.IStartup;
import org.ekkescorner.logging.starter.ide.Activator;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.slf4j.bridge.SLF4JBridgeHandler;

public class AutoStartLogging implements IStartup {

	// logger name = class name
	private static final Logger logger = LoggerFactory.getLogger(AutoStartLogging.class);

	public void earlyStartup() {

		logger.info(Activator.bundleMarker, "earlyStartup slf4j SLF4JBridgeHandler..."); //$NON-NLS-1$	

		// route java.util.logging to slf4j
		SLF4JBridgeHandler.install();

		logger.debug(Activator.bundleMarker, "SLF4JBridgeHandler started"); //$NON-NLS-1$

	}
}

You need this bundle only if you really have to receive log messages from the bundles of your running IDE.

One of my use-cases is the development and test of the redView WYSIWYG Designer – Editor where it’s great to get logging messages from the redView Designer bundles.
you’ll find the overview of this blog series here. stay tuned… part7 follows…

[osgi logging] part 5 – listen to OSGI log reader with Declarative Services (DS)

This is part 5 of my blogseries about ‘Logging in OSGI Enterprise Applications‘ – you’ll find all parts here.

Last year I blogged how to listen to LogEntries from OSGI LogReaderService using a ServiceTracker. In the meantime (since Galileo) Equinox DS (Declarative Services) are part of the SDK. It’s now much easier to add a Listener then before, where you had to write a ServiceTracker.

What’s our goal:

In the last parts I already described how to get all LogEntries from other bundles even if they use Log4J, Commons-Logging or JDK Logging: all Log Messages are catched from our SLF4J / Logback Implementation.

We’re living in OSGI world, so its usual that you also have the need to get the LogEntries logged from bundles using OSGI LogServices: We can read LogEntries using OSGI LogReaderService and simply add a LogListener.

Hint: If you’re in Eclipse – Equniox OSGI world, then we also have to add the ExtendedLogReaderService to get the ExtendedLogEntry.

With a little help of PDE its easy to create a DS Component:

then we have to add References to LogReaderServices and ExtendedLogReaderServices:

In your Component Class you add / remove the LogListeners:

public void addLogReaderService(LogReaderService aLogReaderService) {
	NLogListener listener = new NLogListener();
	logReaderMap.put(aLogReaderService, listener);
	aLogReaderService.addLogListener(listener);
}
...
public void addExtendedLogReaderService(ExtendedLogReaderService aLogReaderService) {
	XLogListener listener = new XLogListener();
	extendedLogReaderMap.put(aLogReaderService, listener);
	aLogReaderService.addLogListener(listener);
}
...
private class NLogListener implements LogListener {
 	public void logged(LogEntry entry) {
	    // do the logging to SLF4J
   	}
}
...

At the end of this blog series all Bundles will be provided with Source, so you can take a look at the Source to see what happened in detail.

If you’re new to DS here’s Neil Bartletts Introduction to DS. You can also use Spring DM or iPOJO – see Heiko Seebergers comparision. So its up to you if you like ServiceTracker, DS, DM, iPOJO,….

In this blog entry I only want to give you one example how to implement LogListeners easy and how to log the catched LogEntries to SLF4J / Logback.

There will be more posts from me about the use of Declarative Services in redView and openerpware later in other blogs – this blog series has the focus on ‘Logging in OSGI Enterprise Applications’ the overview can be found here. stay tuned… part6 follows…