www.wickedshell.net Open in urlscan Pro
2a01:238:20a:202:1086::  Public Scan

Submitted URL: http://wickedshell.net/
Effective URL: http://www.wickedshell.net/
Submission: On October 02 via manual from US — Scanned from DE

Form analysis 0 forms found in the DOM

Text Content

Skip to content


WICKED BLOG

A wicked blog about software architectur, Eclipse and Eclipse RCP


JIGSAW & OSGI – MODULARITY IN JAVA

Recently I read this article about the current status of modularity in Java.
Discussing modularity in Java with collegues turns out to be funny quite often.
OSGi (as the really only reliable modularity framework available) has really
some difficulties when it comes to JEE integration, building or 3rd party
library integration (classloading-hell to be exact…). These drawbacks seem to
somehow reflect to the modularity concept in general – at least for Java.

So I must say that I am really ancious about the 3rd attemp to finally make
modularity a 1st class citizen of Java. I can’t wait to get the first EA of Java
9 supporting the Jigsaw features to see how it looks like!

For anyone who is interested, have a look at the quickstart. Though the current
JDK 9 build is lacking the Jigsaw features, you can get a glimpse of the
concept.
http://openjdk.java.net/projects/jigsaw/doc/quickstart.html

Posted byStefan8. June 2015Posted inGeneralLeave a comment on Jigsaw & OSGi –
Modularity in Java


WICKED SHELL CODE MOVED TO GITHUB

OK, it is pretty late but finally I moved the Wicked Shell code base from
SourceForge to GitHub – https://github.com/stefanreichert/wickedshell

Posted byStefan12. March 201412. March 2014Posted inGeneralTags: GitHub, Wicked
ShellLeave a comment on Wicked Shell code moved to GitHub


XPAND TEMPLATES ON XSDS

The screen definitions of our application are part of our model as well. They
need to be exported to XML to be processed by our screen-interpreter at runtime.
Our client is based on Eclipse RCP and we allow to apply hooks to certain steps
within the interpretation process. This is required to let the developer
implement behavior that differs from the standard behavior of the interpreter.
Hooks are registered via an extensions using the name of a model element for
identification.

The code within a hook references UI elements as it implements UI behavior. To
access an element, it’s name has to be used as well, and that is quite
error-prone. The name within the model might change but the code still
references the old. So we decided to use Xpand to generate descriptors (it is
only a list of String constants to be honest) for the modeled UI elements. The
developer may use the constant, so the code will fail to compile if the name of
the element changes in the model.

Generating these constants is a pretty easy thing as the XSD for the screen
model can simply be used as meta-model.

...
<component class="org.eclipse.xtend.typesystem.xsd.XMLReader">
   <modelSlot value="model" />
   <uri value="${screen.model.project}/model/screen.xml" />
   <metaModel id="screenXMLModel">
      <schemaFile value="${screen.profile.project}/model/screen.xsd" />
      <registerPackagesGlobally value="true" />
   </metaModel>
</component>
...

When activating the XSD metamodel within the project preferences in the Eclipse
IDE, the Xpand editor recognizes an XSD in the project’s classpath as metamodel
and you may start creating the templates.
Pretty easy and very handy!

Posted byStefan6. July 20107. July 2010Posted inEclipse, Model Driven
DevelopmentTags: Eclipse, MWE, XpandLeave a comment on Xpand templates on XSDs


EXECUTING COMMANDS PROGRAMMATICALLY

Executing commands (e.g. from a SWT listener) is a pretty handy thing. You don’t
have to care about, where the handler is registered, you simply execute the
command via the ICommandService, the delegation is provided by the framework.


...
ICommandService commandService =
(ICommandService)getViewSite().getService(ICommandService.class);
try {
commandService.getCommand("com.foo.the.command").executeWithChecks(new
ExecutionEvent());
}
catch (Exception exception) {
logger.error(exception.getMessage(), exception);
}
...


There is just one thing about the snippet above that is bad: The way the
ExecutionEvent is created. Using the default constructor results in hard time
for a handler, as the HandlerUtil class cannot be used due to the missing
context information. A better way is to pass on some parameters to the
ExecutionEvent to be created. The most important one is the last parameter, the
application context object. It can be obtained via the IEvaluationService.


...
ICommandService commandService =
(ICommandService)getViewSite().getService(ICommandService.class);
IEvaluationService evaluationService =
(IEvaluationService)getViewSite().getService(IEvaluationService.class);
try {
Command theCommand = commandService.getCommand("com.foo.the.command");
theCommand.executeWithChecks(new ExecutionEvent(theCommand, new HashMap(),
control, evaluationService.getCurrentState()));
}
catch (Exception exception) {
logger.error(exception.getMessage(), exception);
}
...


This command invokation can be processed by any handler using the HandlerUtil
class.

Posted byStefan25. March 201026. March 2010Posted inEclipseTags: commands,
Eclipse RCPLeave a comment on Executing commands programmatically


TUNING XPAND TEMPLATES

Our current project is model driven, using MWE, Xpand & Xtend. Right at the
beginning, our templates were really fast and the round trip time was fairly
acceptable. By now, our model contains quite a lot of elements and a generator
run takes far more time than before. So I had a look what can be done to tune
our templates a little.
When studying the Xpand docs, I found something interesting: The cached keyword
for Xtend functions. A return value of cached functions is stored for the given
parameter(s) and this turns out to be very useful. We have a lot of typeSelect()
operations to do something on specific model types, for example on all our
Services, in both Xpand templates and Xtend functions.
... eRootContainer.eAllContents.typeSelect(Service) ...
This statement results in scanning the whole model for elements of the desired
type. Usually you expect the result to be the same each time (at least you
should hope). This piece of code is a perfect example for a cached Xtend
function that replaces all occurrences of the upper statement.

cached List[Service] services(EObject eRootContainer):
eRootContainer.eAllContents.typeSelect(Service);

So the model is scanned only once, as the eRootContainer is always the same
object. This saves a lot of time. If you provide such a function for each type
you need, your templates will be processed much faster. I know, caching is a
little dangerous, but well dosed it can be quite useful and reduces the required
time for a round trip.

Posted byStefan2. March 20104. March 2010Posted inModel Driven DevelopmentTags:
MDD, MWE, Xpand, XtendLeave a comment on Tuning Xpand Templates


ECLIPSE RCP AND LANGUAGE SELECTION

Eclipse RCP Clients are usually shipped with language bundles providing the
translations of the application’s labels. Depending on the locale (either the
system’s default locale or the locale set with the -nl program argument), the
client appears with the labels in the defined language. But what about letting
the user choose his language, e.g. in a login dialog or during runtime?
Well, simply modifying the default locale using Locale.setDefault() has no
effect as the underlaying workbench has been already configured with the startup
language. You actually need to restart the client and reset the default locale.
Eclipse provides a special exit code IApplication.EXIT_RELAUNCH in order to
relaunch a client and use programmatically defined startup parameters. To do so,
simply set the system property eclipse.exitdata with the required startup
parameters with System.setProperty(). The prefix of the property’s value should
be {eclipse.vm}\n, the rest is to be structured like the common .ini file, that
is usually used to set the client’s startup configuration. In order to reset the
locale, the property’s value needs to contain the -nl program argument set to
the language selected by the user. When exiting the Workbench using the
IApplication.EXIT_RELAUNCH exit code, the client will then be relaunched using
the configuration defined with the eclipse.exitdata property’s value and appear
in the requested language.

Posted byStefan11. February 20104. March 2010Posted inEclipseTags: Eclipse RCP,
language selection2 Comments on Eclipse RCP and language selection


BUILDING SOURCE FEATURES WITH THE PDE BUILD

The PDE Build provides a pretty convenient way of automatically creating a
source feature. The additional feature contains all source files and artefacts
listed in the containing bundles’ build.properties files for a source build.
There are only a few settings necessary.

Assume we have a feature com.foo.feature containing some bundles with binaries
only.

First, we need to configure a source feature include for the feature. Simply add
a line to the com.foo.feature feature’s feature.xml:
<includes id="com.foo.feature.source" />

The linked feature com.foo.feature.source does not exist yet, it will be created
by the PDE Build later on.

To get the PDE Build actually creating the source feature, we have to edit the
com.foo.feature features’s build.properties by adding another line to it:
generate.feature@com.foo.feature.source = com.foo.feature

The PDE Build will now build the linked source feature com.foo.feature.source
including a bundle containing all sources of all binary bundles included in the
com.foo.feature feature. Since Eclipse 3.4, we can tell the PDE Build to create
an individual source bundle for each bundle by setting a PDE Build property
individualSourceBundles to true.

Posted byStefan30. January 20104. March 2010Posted inEclipseTags: Eclipse RCP,
PDE build, sourceLeave a comment on Building Source Features with the PDE Build


FRAGMENTS VS. BUDDY CLASSLOADING

Classloading is a serious issue when creating OSGi based applications. As each
bundle is bound to it’s own classpath, sometimes the reflection mechanism will
not work as expected. So, there are basicly two ways of solving the problem of
extending a bundle’s classpath (when using Equinox…), either create a feature or
use Buddy Classloading. But which solutions fits best for what problem?


FRAGMENTS

A fragment is an OSGi mechanism to allow a dynamic extension of a bundle at
runtime. The fragment itself is not a true component as other bundles may not
define a dependency on the fragment. It is used for different purposes such as
testing, internationalisation or logging configuration. You can add system
dependent code or configuration files to a generic implementation. The good
thing is, that the extended code has no dependency on the fragment i.e. does not
necessarily require the fragment for running (for example testing fragments).

How to
A fragment is structured as a common bundle. It may be created using a wizard
(in Eclipse) or by adding a line to the manifest.mf of a common bundle defining
the so called fragment host:
Fragment-Host: bundleSymbolic-Name
This advises the runtime to merge the fragment’s content with it’s host at
runtime.

What’s good
Fragments are pure OSGi and provide the flexibility of extending a component
dynamicly at runtime without breaking the component architecture. Some third
party classpath requirements can be solved this way, for example providing a
logging configuration.

What’s bad
Some third party classpath requirements cannot be matched using fragments.


BUDDY CLASSLOADING

Buddy Cassloading is somewhat a hack (in my opinion), as it adds a bundle’s
classpath to another’s – you could call it ‘reverse-dependency’. In OSGi terms,
this is explicitly not wanted as a bundle should be treated as a component. But
since many Java libraries got used to a single classloader environment, they
still expect an exclusive access to any class of the application using
reflection. So, in some situations, you can’t really avoid using Buddy
Classloading in an Equinox environment.

How to
The manifest.mf of the bundle to be extended receives an additional line to
define a Buddy Policy:
Eclipse-BuddyPolicy: registered
This defines the bundle to be aware of registered bundles which entend the
classpath.

The manifest.mf of the bundle to extend receives two additional lines:
Eclipse-RegisterBuddy: bundleSymbolic-Name
Require-Bundle: bundleSymbolic-Name
This defines the bundle to extend the classpath of the listed bundles.
Additionally, the registered Buddy Policy requires the extending bundle to have
a dependency on the extended bundle.

What’s good
Buddy Classloading easily enables using common reliable libraries without any
problems. Additionally, the extending bundle can still be treated as a ‘normal’
bundle, other bundles may have a dependency on the bundle and use the exported
packages as provided.

What’s bad
Buddy Classloading is not ‘the OSGi way’ as it corrupts the idea of having a
component based application with clearly separated bundles defining an interface
and dependencies. Buddy Classloading is an answer to a technical problem and
should not be used for application design.

Posted byStefan27. January 20104. March 2010Posted inEclipse, Software
ArchitectureTags: architecture, buddy classloading, bundle design, Eclipse RCP,
fragment, OSGi2 Comments on Fragments vs. Buddy Classloading


WICKED SHELL DOCS

I have updated the Wicked Shell page with the contents of the Wicked Shell
documentation. It is not that detailed, so if there are any questions, please
let me know via mail.

Posted byStefan31. December 20094. March 2010Posted inEclipse, PersonalTags:
Wicked ShellLeave a comment on Wicked Shell Docs


WHITE CHRISTMAS

Unbelievably 3 days before Christmas Eve it is freezing cold outside (we had
-11,7 °C) and everything is covered with snow. So there really is a chance for a
white Christmas around here, which is pretty special.  I can’t really remember
the last time we had snow for Christmas.


Posted byStefan21. December 20094. March 2010Posted inPersonalTags:
PersonalLeave a comment on White Christmas


POSTS NAVIGATION

1 2 3 4 Older posts


G’DAY FOLKS

My name is Stefan, I live near Hamburg, Germany, and I am interested in software
developement, software architecture, model-driven-development, Eclipse, Eclipse
RCP and - occasionally - some other stuff...


MY BOOK

Stefan Reichert
Eclipse RCP im Unternehmenseinsatz
dpunkt.verlag | amazon.de


BLOGROLL

 * Dirk Rademann's Blog
 * Kanapeekartoffels Filmtipps
 * Planet Eclipse

Wicked Blog, Proudly powered by WordPress.