ekkes corner - eclipse mdsd osgi oaw erp

moved ekkes-corner blog to wordpress

2009-05-26T09:45:00.004+02:00

Last days I moved my blog "ekkes-corner" from Blogger to Wordpress. I was impressed how easy all my existing blog entries and comments are imported. Some are looking not exactly the same as before, but over all it worked great.

All my new blogs will now be there at Wordpress - hopefully the Feed of Planet Eclipse will be updated soon.

Eclipse 3.5 (Galileo) is coming - and its a good idea for you to become a Friend of Eclipse

Many new cool things in the area of PDE, Target Platforms, Runtime, Riena, Modeling (EMF, oAW) - I'll report about my experiences and give some tips and tricks in my upcoming blog posts.

stay tuned...

ekke

New Ways Around Generation Gap Pattern - VideoCast

2009-05-11T06:42:00.006+02:00

To demonstrate the use of VetoRedirectStrategy in oAW workflows (see my last blog entry "New Ways Around Generation Gap Pattern") I created a videocast - movie.

After publishing my first videocasts I learned that there are sometimes problems to play them in different browsers. So I publish my screencasts in different formats - you can use what fits your environment.

http://vimeo.com/ekkescorner as HD movie
http://ekkes-corner-tv.org as QuickTime
http://www.slideshare.net/ekkescorner as slides (no audio or animation)
iTunes: as VideoCast for iPod/iPhone or AppleTV/desktop (To subscribe from iTunes Store search for „ekkes-corner“)

Have fun.

ekke

New Ways Around Generation Gap Pattern

2009-05-05T12:06:00.028+02:00

This blog dsescribes some new ways around "Generation Gap Pattern (John Vlissides)".

ModelDrivenSoftwareDevelopment (MDSD) - Best Practices

Some best practises are valid at all MDSD projects:

generated code should be clearly separated from manually written code
generated code should not checked into a VersionControlSystem (CVS, SVN, GiT)

Inside a MDSD (ModelDrivenSoftwareDevelopment) project there are different types of code (see also Heiko Behrens article)

Manuelly written code

Code never be generated, always manually written. This can be some base framework classes or code only used at some places not worth to generate like Utility- or Helper classes.

Generated unchanged code

Such code will be always generated and never changed manually. Classes will be re.generated at each run of the generator - existing files are overwritten or destroyed before.

Generated but editable code

This is code where its useful or ecpected that the generated code will be changed or extended. If files exist, they will not be overwritten - new files will be added and generated first time. (generate-once)

Generation Gap Pattern

The main problem with generated code is always how to combine or separate generated code and manually changed / extended code. That's the point where in most cases the Generation Gap Pattern will be used:

Generated classes will be generated into a directory which is cleared before generation. Subclasses will only generated first time into another directory where they can be changed.

In practise some problems happen - per ex. "Ghost Classes" after refactorings / renaming. Also you cannot differ between generated and changed Subclasses - so all will be checked into VersionControlSystem.

To make this more practicable, Heiko Behrens describes „Conditional Generation“ where generated and changed Classes are clearly separated. oAW Workflow can use a "Vetostrategy": Before generating an artifact it will be tested if there's already a changed artifact into another direcrtory - and if found no new generation happens.

This is described in detail in Heiko Behrens article „Generation Gap Pattern“. If you dont have read this article, please do now. I expect that you know the VetoStrategies described by Heiko !

Thanks to Heiko Behrens I got the information about oAW „VetoStrategy“ which was new for me - never read about it in the docs or forum. Now I was inspired to find some solutions for my project better then previous workarounds.

At first I must say, that I have some problems to use the „Generation Gap Pattern“ as generic pattern if generated code also has to be modified in MDSD projects. Working as softwarearchitect and designing an entity model (esp. in the domain of Enterprise Business Applications), I very carefully think about inheritance strategies / hierarchies. (esp. if all must be mapped from Hibernate or EclipseLink to a database)

A really simple inheritance:

If you follow the „Generation Gap Pattern (John Vlissides)“ :

... separating Classes into one generated (often abstract) Class and one additional (often first-time-generated) editable Subclass ...

use of generation Gap Pattern in many oAW projects

... then the inheritance - hierarchy becomes "dirty" from my point of view. In big projects suddenly hundreds of classes are "twice" - and the only reason is technically: because its a modeldriven project ?

I only want to use abstract / concrete classes or super- / subclasses if I need them from my use-cases or software architecture, but not because I'm using a generator - framework.

As always using a pattern you should ask: is it the right pattern or are there other ways to reach the goal ?

From my opinion: the "Generation Gap Pattern" helps in many cases, but not always. Heiko Behrens shows how the use of "VetoStrategies" in oAW workflows will help handling the files and folders, but its no solution to avoid getting many classes twice which bloats the architecture.

Protected Areas

So we again have to find an answer how to separate generated and manually written code without breaking the rules of best practises in MDSD projects.

There is another way: „ProtectedAreas“. STOP crying ;-) please read ahead - I try to use protected areas something different then normaly !

What are „Protected Areas“ ?

If there are some parts of the code where its allowed to modify or extend, then the Begin and the End are marked as special comments identified by an unique ID. Inside these protected areas the default code will be generated and the area will be marked as DISABLED, so if regenerating it will be overwritten.

If a developer modifies / extends the content af a protected region, then this region has to be ENABLED and the changes are protected after regeneration. Using „Protected Areas“ the structure and inheritance of your classes remain unchanged - exact the same as using it without a generator.

How are „Protected Areas“ normaly used ?

Whats the drawback ?

Now classes have protected areas, can be overwritten if regenerated but then they will be checked into VersionControlSystem - thats bad, because there are many classes without changes: only generated content. That breaks the rule "never check-in generated code".

Also you dont see which classes have changes and which are untouched after generation.

Protected Regions using VetoRedirectStrategie

Here's my solution

at start of generator-workflow clear „src-gen“ and „veto“
generator scannes „src-gen-pr“ and caches ENABLED ProtectedAreas
„only-generated“ classes will be generated into „src-gen“, also classes with „ProtectedRegions“ without a veto
classes with ENABLED „ProtectedRegions“ are stored in „src-gen-pr“
while generating the generator checks using "VetoStrategy" if a class is already in „src-gen-pr“. If found, then the generated output is redirected into „veto“ directory where the new generated class together with ENABLED ProtectedRegions (from cache) is written to
as last step of generation the files from „veto“ are compared with corresponding files from „src-gen-pr“. Only if they differ, the new ones will be copied into „src-gen-pr“. Now we are sure only really changed files will get a new modified flag and checked into VCS.

The Workflow

Generated-only and manually changed code now is clearly separated. Only changed artifacts will be commited into VCS and the Inheritance structure is unchanged.

Of course I have to watch, that a developer changing „Protected Regions“ doesnt forget to activate them (ENABLED) and to move the file into „src-gen-pr“ if not already there.

If you want to check if a developer ENABLED a protected region, but forgets to move into „src-gen-pr“ you simply can add a step at start of your workflow: scan „src-gen-pr“ for protected regions - if some enabled are found, stop workflow with warning.

If you want to check if a developer forgots to enable a protected region after making some changes, you can include something like a checksum into the region and write a component to test these before starting to generate.

All is possible you see - but its of course a matter of time: each extra step will slowdown generation performance.

(Tip: sometimes the Local History of Eclipse helps - but there's currently a bug: oAW generator overwrites the last Local History entry instead of inserting a new)

Inside the default code of a „ProtectedRegion“ I always insert a comment like:

Disabled Protected Region:

Enabled Protected Region:

Some Tech Infos HowTo implement a RedirectVetostrategie

tested using:

Eclipse 3.5M6
openArchitectureWare 4.3.1 (If you already use the plugins from Eclipse Modeling Project you have to change the namespace)
Apache Commons IO 1.4 (SpringSourceEnterpriseBundleRepository - (Eclipse Orbit only has version 1.3.2 from 2007)

Workflow Components

Workflow Component Directory Cleaner (oAW Component)

outlet.src.dir points to src-gen,

outlet.veto.pr.dir points to veto.

Workflow Component Outlet with Vetostrategy (Redirect of enabled ProtectedRegions)

This Outlet uses a new Vetostrategy - also the Outlet Class was extended

outlet.src.dir points to src-gen,

outlet.src.pr.dir points to src-gen-pr and

outlet.veto.pr.dir points to veto.

Workflow Component „fileReplacer“ (Replace files from src-gen-pr ?)

A new Workflow Component compares corresponding files in veto directory and src-gen-pr directory and replaces modified ones.

A short view inside the new Classes and Interfaces

Class OutletWithVetoRedirection (extends oAW Outlet)

Interface VetoRedirectStrategy (extends oAW VetoStrategy)

vetoRedirectSourcePath points to src-gen,

vetoRedirectOutputPath points to veto

Class CondGenVetoRedirectStrategy (implements VetoRedirectStrategy)

hasVeto always returns false zurück, because we dont give a veto like from other VetoStrategies described by Heiko Behrens - we only want to redirect the Ouput Path into veto Directory.

Classe ReplaceVetoRedirectedFiles (extends oAW AbstractWorkflowComponent2)

Using Apache Commons IO its very easy to compare file-content and to copy files from one directory to another.

outputFile represents a file from veto,

sourceFile represents a file from src-gen-pr

-------------------------------------------------------------------------------------

Important hint:

I was inspired to write this blog after reading the excellent article from Heiko Behrens: „Generation Gap Pattern“.

Heiko Behrens shows concrete solutions how to better handle „Generation Gap Pattern (John Vlissides)“ if using oAW (openArchitectureWare) Workflow und Xpand / XTend. This blog is not an alternate solution - only an extension !

-------------------------------------------------------------------------------------

Summary

From my point-of-view the use of „Protected Areas“ combined with „Conditional Generation“ can be very useful in some projects. Best Practises rules are not broken.

But as always: „Its Your Choice“ - it depends from project and use-cases what makes sense.

Heiko Behrens showed some strategies - if you add my ProtectedRegion strategy, I think you'll find the right for your project - or perhaps its the starting point to try it out.

Inside a big project there's no problem to use different strategies side-by-side.

Hope I gave you some new ideas.

ekke

Blog in german

oAW goes Eclipse Modeling

2009-05-05T09:41:00.008+02:00

openArchitectureWare

goes --> Eclipse Modeling Project

During the last months oAW (openArchitectureWare) was integrated into Eclipse projects - the so-named oAW 5.0 will be in reality the first oAW Eclipse release as part from Eclipse Modeling Project inside the Galileo train:

oAW Workflow --> Eclipse EMFT Modeling Workflow Engine (MWE)
oAW Xpand/Xtend --> Eclipse M2T Xpand
oAW Xtext --> Eclipse TMF Xtext

Starting with Eclipse 3.5 M7 it would be great if many oAW user will test, if oAW 4.3.1 projects are running well using Plugins from Eclipse Modeling. (if not please report Bugzillas)

Perhaps someone will ask: why is there still an openArchitectureWare project, if all was moved to Eclipse into different projects from Eclipse Modeling ?

Eclipse Modeling contains uncount sub-projects (see also JAX session from Jan Köhnlein „Eclipse Modeling Overview“).

oAW is something like a distribution - a container of some sub-projects running well together - making it easier für users to find out out the right combination to build projects using oAW-like MDSD.

oAW is also a very active community providing much KnowHow and Support for model-driven development - look at the forums here.

There also exist some additional projects around oAW not moved to Eclipse - so try out the new Eclipse Modeling Workflow (MWE), Xpand (M2T) and Xtext (TMF) but stay tuned at openArchitectureWare.

ekke

blog in german

OSGI Enterprise Applications: Monster Bundles from 3rdParty

2009-04-30T11:59:00.005+02:00

The (OSGI) world could be so wonderful, all are brave OSGI citizens:

one JAR file == one Bundle
import-package used for common dependencies
(required-bundles if used only in the own namespace)
...

If you have to develope OSGI Enterprise Business Applications, then in most cases you have to integrate 3rdParty bundles, - projects, -frameworks.

And then it can happen, that a 3rdParty project looks good on the very first view: some bundles, well structured, dependencies make sense, but..... why is this core bundle so big ?

Here you'll find the answer: „looking into 3rdParty OSGI bundles“

Perhaps the Composite Bundles from upcoming OSGI R4.2 (here and here and Richard Halls Session at JAX09) can help to encapsulate such monster bundles ? I'll try and report....

ekke

blog in german

JAX09 - HowTo build an OSGI EJB3 Server - Slides online

2009-04-30T11:05:00.008+02:00

Last week I was at JAX conference in Mainz - as always some great days. Most important for me are discussions with friends and networking.

On Friday at OSGI Experts Day I had a session and could give an overview of my OSGI EJB3 server:

Session "HowTo build an OSGI EJB3 Server"

Eclipse as IDE and Platform for RCP and Server
OSGI - Equinox
Eclipse PDE (OSGI Bundle Tooling)
Eclipse Riena (Remoting, UI)
EasyBeans (EJB3 OSGI Bundles)
Drools (Rules Engine, Business-ProcessFlow)
redView (Riena EMF Dynamic Views)
open-erp-ware (OSGI - ERP - Enterprise Application)
Model-Driven Development (oAW - OpenArchitectureWare XPand, XTend, Xtext, Workflow)
and more...

Uploaded the slides, so you can watch them here:

SlideShare (without embedded Screencasts)
Vimeo (as HD Video inclusive Quicktime Screencasts)

Next days I'll produce some episodes for my VideoPodcasts at ekkes-corner-tv.org and publish the session with audio added and some more details.

ekke

blog in german

redView - Dynamic Views for Business Applications

2009-04-08T22:48:00.010+02:00

This year at EclipseCon in Santa Clara I presented first time the new Open Source project "redView" - started from Florian Pirchner and me.

The session was presented without the usual "slides-to-read-while-speaker-speaks". I was inspired by the book "Zen and the Art of Presentation" to make another kind of presentation.

But if you present a session in Zen - style, you couldn't only publish your slides to people not hearing you live. A Zen - style - session is only the half of work - you also have to publish detailed technical informations in an extra document.

In this case - those details will be published soon at redview.org to download.

If you were not at EclipseCon or visited another slot and want to know what I have presented, you're not lost - you can watch a Video Podcast:

ekkes - corner - tv just started

As an addition to my blogs in english and german language now I also will publish regular an english Video Podcast at ekkes - corner - tv.org:

I'll talk about and make live-demos about:

Eclipse as IDE and Platform for RCP and Server
OSGI - Equinox
Eclipse PDE (OSGI Bundle Tooling)
Eclipse Riena (Remoting, UI)
EasyBeans (EJB3 OSGI Bundles)
Drools (Rules Engine, Business Process Flows)
redView (Riena EMF Dynamic Views)
open-erp-ware (OSGI - ERP - Enterprise Application)
Model-Driven Development (oAW - OpenArchitectureWare XPand, XTend, Xtext, Workflow)
and more...

If you want to subscribe my Video Podcast:

open iTunes Store, search for „ekkes-corner“ and subscribe. There are two different formats available: for iPod/iPhone and for Desktop/AppleTV).

If you don't use iTunes Store you can read it directly from my web site: ekkes-corner-tv.org or subscribe RSS Feed from there.

The first episode presents the redView Session from EclipseCon.

EclipseCon was as usual: very short nights - but also much fun to meet all the friends again and to learn much.

Next months will be very hard:

redView should be published beginning of may 2009
my OSGI - Equinox - Server should run under Galileo
my ERP Enterprise App should go live in summer 2009

Not to forget: this month is JAX 2009 in Mainz (Germany) where I speak at OSGI Experts Day

There will be some Blogs and Video Podcasts to reflect all this work... stay tuned...

ekke

Using RCP Views to view UML Diagrams ?

2009-03-19T20:13:00.011+01:00

Who doesn't know this:

You as Software Architect have listen to your business users requirements and designed such great UML diagrams - and now you present them proudly - but your business users don't understand what you designed. They couldn't imagine what all those dependencies, relations, inheritance, 0..1, 0..* mean.

What if you could generate by-magic RCP views directly from your UML model ?

...and your business users can understand what your diagrams mean and also see those little hidden secrets from properties like "length of a String" causing the RCP View to show a single line or multi-line text field ?

...or showing fields marked as index as required with yellow background ?

...or showing your Enumerations as SingleChoices or Combos ?

Utopia ?

No - this is the way to realize it:

use openArchitectureWare to generate from your UML Model Java Code, Configuration Files, EMF Models and more

use redView to auto-magically generate dynamic Views from your EMF Models

(Hint: the first 3 TabItems represent 0..1 or 1..1 associations, the last two TabItems contain a Table and represent 0..* or 1..* associations)

Curious ?

Then visit on Thursday at 2:30pm Room 206 Session

Dynamic Views for Business Applications (Riena + Eclipse Modeling: EMF, oAW)

at EclipseCon!

redView is a part of a complex enterprise solution - if you want to know more about my OSGI - Equinox - Riena - Easybeans Serverproject please visit JAX09 in Germany and book the OSGI ExpertsDay.

ekke

blog in german

Books and Conferences for Eclipse Plug-in Developers

2009-01-29T15:13:00.008+01:00

Here are my Top 3 of new published books I'm using in my daily work of developing Eclipse Plug-ins in a model-driven way...

OSGI Service Compendium
EMF - Eclipse Modeling Framework
eclipse Plug-Ins

... now I only have to wait for the announced books of RCP and OSGI/Equinox - developing ;-)

Yesterday I met Eric Clayberg and Dan Rubel in munich and received one copy of their new „eclipse Plug-ins“ book. Because I couldn't wait, I already had bought it two weeks ago. Now Florian Pirchner has luck, because he'll get this one - think he can use it for his work on redView (Riena EMF Dynamic View).

Also good news for UI developers using Riena Ridgets: the integration / code generation from SWTDesigner will be better in the near future, Eric told me.

BTW: Who doesn't know: Riena is read-to-go for version 1.0. Congratulation !

We' ll also try to make it easy to insert dynamic SWT Components (generated from redView) into SWTDesigner.

Then you'll be able to design complex views using a comfortable GUI Designer and also include dynamic Components (like adress fields, ...) ... of course including databinding, Riena Markers and more.

If you're going to EclipseCon dont miss our session about redView:

Dynamic Views for Business Applications (Riena + Eclipse Modeling: EMF, oAW)

And if you couldn't make it or you want to know something more about the whole project - you can come to my session at JAX 09 / Eclipse Forum Europe 09 conference - OSGI Experts Day:

How to build an OSGI Enterprise EJB3 Server.

ekke

UserInterface in OSGI Enterprise Applications

2009-01-21T15:30:00.007+01:00

Christmas time is over...

... and so its time to publish something. The last weeks ware filled with hard and intensive work to make my OSGI Enterprise Application run. Main work at the moment is the design of the Userinterface(GUI).

One part of the GUI - development I'll present at EclipseCon 2009, together with Florian, the Plug-In developer of redView. (redView = Riena - EMF - Dynamic Views)

The idea to create the redView project was born some months ago, as I was discussing with Florian the problems to design a GUI for a complex ERP Enterprise solution. Such an Enterprise Application with hundreds of Entities and high quality and comfort for the users to work with should be designed using a GUI Designer.

I decided to use SWTDesigner from Instantiations as GUI Designer tool - from my experiences a really great application.

An ERP Enterprise Application has many high specialized windows (views), but also hundreds of standard - views. Standard views are looking same and most parts of the views can be generated from the Entity - data model.

Because my ERP Application is model-driven (using openArchitectureWare) the first idea was to generate the Java code of those views.

But if you generate Views there will be always usecases where the business user wants to change "only something". If you do this using SWTDesigner then the Java code will be changed and cannot be generated again. So its difficult to manage this, if the model changes, attributes were added or so. Of course its a good idea to generate the first version of the views to make it easier to start designing.

My OSGI Enterprise Application already uses Eclipse Riena for Remote OSGI Services. Riena also has some nice things if you're devloping a GUI.

Riena makes the programming of UI easier and uses Ridgets (encapsulated SWT Widgets). You dont lose flexibility because if you need it, you can access the SWT widgets, too.

Riena Ridgets also separate UI and Controller and make configuring Eclipse Databinding much easier.

In Enterprise Businessapplications you always have to decide:

should this element be displayed ? (depends on Usecase or Data)
is this element required ? (the user must enter data)
is it a read-only element ?
are there validation rules for this field ? (Phonenumber, email, from-to value, date, ...)

Riena provides the concept of Marker and Validation making programming these things also much easier- and you're sure that it will always look the same in your whole application.

If the code was generated you'll get some informations for Markers and Validation already from the Entity model or Business-Process model. (An attribute marked as Businesskey or Index should be a required field) So you'll get many defaults generated.

If you're using Riena there are some problems designing with SWTDesigner, because the code generated from SWT Designer doesnt know the Riena - concept of splitting Controller und UI - but hopefully in the future the integration will become better.

Riena also includes a complete UI concept with own LookAndFeel, navigation and nice designed perspectives, where a perspective can be a subapplication of the enterprise application.

The Riena UI is clear, easy-to-use and doesn't confuse a business user with all the functionality of Eclipse RCP. But (for me) there's a downside of this concept: Riena always has only one View open at a fix position. There are many UseCases in an ERP Application where I need more then one View opened including Drag'n'Drop between the Views. I'll see if there will be ways in the future to combine this, because I would like to use some of the cool things Riena provides for UI - development.

But all of this is no answer how to design Views of Enterprise Applications in model-driven frameworks: what can be generated without losing flexibility in design ?

So we're back at my discussions with Florian last autumn. Our vision:

Wouldn't it be great to have a GUI including all the comfort from Riena, dynamically created at runtime depending on an EMF Metamodel ?

... and these EMF models for each View itself are generated using openArchitectureWare from UML Entity- and Businessprocess - models ?

... and having a graphical designer - editor, where a business user or - programmer can easyli change the generated Views ? (Drag and Drop to change the order / position of elements, add or change validation rules, add or change Riena Markers, Fonts, Colors,....)

... and wouldn't it be great to combine these changed EMF models with changes from UML models next time generating the Views again ?

This was a vision in october 2008 - now we're knowing that it works ( I already generated some hundred Views for the ERP project successfully) and we'll present it at EclipseCon 2009:

Dynamic Views for Business Applications (Riena + Eclipse Modeling: EMF, oAW)

an Entity in UML class diagram (MagicDraw)

oAW Xtend creates EMF elements using UML model with JPA Persistence Profile

redView Designer with generated elements - the yellow marked entry field indicates a Riena Marker „required“

EMF Outline View with generated elements

The Properties View of one GUI element.

Its still some work to finish all aspects of databinding, I18N, Platform - independence (at the moment tested on OSX and Windows), and using Styles and Themes.

Hard weeks, short nights, bit it's fun to work with Florian and to make a vision reality.

Now these are the ways to design the GUI of my ERP Enterprise Application:

Standard Views will be generated using oAW as EMF models
redView creates dynamic Views from these EMF models
Spezial Views can be generated first times from oAW
Standard Views can be designed using redView Designer
Spezial Views will be designed using SWTDesigner
Riena Ridgets, Marker and Validation is used

The last years I was using EMF only indirectly and all my generation of code and artifacts using oAW was based on UML. No I reached the EMF world as so many others, too ;-)

The flexibility of EMF and the good integration into oAW is really great - it is so easy to work with UML and EMF together.

I'll report in detail about all different aspects of designing UI in Enterprise Applications from my point of view. Because its a complex story, I started a new blog series "UI in OSGI Enterprise Applications". Of course I'll also compare the pros and cons using some of the other great UI projects or how to combine them.

... stay tuned.

... the other blog series about Logging, Server, Declarative Services will also be continued - all belongs together.

ekke

the blog in german

EclipseCON 2009 Riena - EMF - oAW and more

2008-12-18T12:13:00.007+01:00

This time I'll not only visit the eclipseCON - one of my submissions was accepted:

Dynamic Views for Business Applications (Riena + Eclipse Modeling: EMF, oAW)

I'm very happy about this. This was the second really good news last time - first was at german W-Jax where I became a member of the oAW Team.

redView (Riena - EMF - Dynamic View) is a sub-project of my model-driven OSGI Enterprise Application. redView will be Open Source (EPL). Dynamic views from redView can be used stand-alone or in combination with openArchitectureWare (oAW). ... I'll talk more about this next weeks

This week was a heavy update - week:

OSX 10.5.6
MagicDraw 16.0
openArchitectureWare 4.3.1RC3 und RC4
Riena M6
EasyBeans 1.1.0 Snapshots

Thanks to EasyBeans - Team (they added some properties for Declarative Services) I can continue my work to switch from ServiceTracker to Declarative Servics (DS) and there'll be new blogs also coming soon.

stay tuned...

ekke

BTW: dont wonder if my submission 391 has no author. I tried to add my assistant as co-author, got an error and now the submissions has lost author and assistant. reported a bugzilla...

Logging in OSGI Enterprise Applications, Part 6

2008-12-10T16:16:00.013+01:00

This part of my blog series "Logging in OSGI Enterprise Applications" will talk about openArchitectureWare

...and logging with SLF4J / LogBack.

The previous blog entries from this series described logging from the Runtime of an OSGI Enterprise Application. The whole Client / Server Project is model-driven based on Eclipse Modeling Project: EMF, UML2 and as engine the generator framework openArchitectureWare.

The MDSD - aspects of the application will be part of another blog series.

Now we want to take a look at logging with SLF4J / LogBack while working with openArchitectureWare.

openArchitectureWare (oAW) in Target Platforms

If you want to use oAW in a Target Platform with SLF4J / LogBack as Logging Framework together with bridges to Commons Logging and Log4J, you'll notice some problems: Many of the oAW bundles are using Require - Bundles instead of Import - Packages as dependency to logging bundles.

I opened a Bugzilla, but it seems its too late for 4.3.1.

If you need it now, thanks to PDE its easy: Import Bundles in your Workspace, change Dependencies to Import Package, then export the Bundle als Plug-In again.

openArchitectureWare (oAW) Workflows

There's an own Launcher for oAW Workflows (Run Configurations | oAW Workflow) - we have to change the Classpath:

Click on User Entries and then Add Projects...

...choose the Logging - Projekts from workspace

...and save changes with Apply.

You have to put the logback.xml (or logback-test.xml) directly under src/ into the project which starts the oAWworkflow. In this xml file we configure the logging from the workflow - doesn't matter if the logoutput was originally sent to Log4J, Commons-Logging or OSGI LogServices.

To control please start a Workflow with debug="true" in your logback.xml.

If all is configured right, then the Console will list at first the logback - configuration and then all log - output from the Workflow sent to our configured Appender (Console, Socket, usw)

Blog Series "Logging in OSGI Enterprise Applications":

Part 1: An overview

Part 2: How to catch all log events from "classic" logging - frameworks

Part 3: How to catch all log events from OSGI Log Services

Part 4: How to start logging bundles the right way inside an OSGI Enterprise application

Part 5: Configuration, Fragment-Bundles, Markers

Part 6: Logging and openArchitectureWare Workflows

Part 7: ... follows (Stay tuned...)

Perhaps some of my older blogs about Logging und OSGI are also interesting:

Logging (Riena - EasyBeans - Equinox) reloaded

Catch-22 Logging in OSGI Environments

blog in german

Comparing Files And Folders After Codegeneration

2008-12-10T09:31:00.012+01:00

Eclipse has great possibilities to compare files and folders with each other or history.

But I'm also using external tools:

Some time ago I blogged how to use NameChanger (Freeware) under OSX to rename files where the bundle names aren't named like eclipse bundles (plug-ins) using "name_version".

Also for creating of target platform - locations I'm using a tool to get unique sets of bundles. My blog „Avoid Duplicate Bundles“ desribes the use of FileMerge (under OSX part of XCode Tools).

Now I was looking for an intelligent tool to see if generated code is identical to an older version. This generated code is not checked into a sourcecode repository, because its always regenerated. Before starting the generation those directories werde cleared, so there's also no local history in Eclipse.

While testing 4.3.1RC2 of openArchitectureWare I was interestd to see if the generated code is identical to version 4.3.0.

Its not so easy because there are some allowed differences like:

* generation started at: 9. Dezember 2008 08:04:13 CET

Those generation timestamps should be "identical" to lines with another timestamp. FileMerge from OSX was no help, because these files are reported as different.

Next try: Compare Folders compares the size of files and also reports added or missing files. If the generation timestamp hase same length, then the files are identical otherwise not:

... I also dont know if the other content is identical - I need the compare more detailed. I found DeltaWalker where I can do waht I want. But the best of all is:

DeltaWalker is an Eclipse RCP Application :-)

...and available for OSX, Windows, Linux. Now it was easy to see if the generated code is the same as before:

Create a File - Filter, where lines of different generation timestamps are identical:

Create a Folder- Filter ignoring OSX-specific .DS_Store Files:

Then hitting Compare::

All the same :-)

congratulations openArchitectureWare

- in all my projects no differences found between 4.3.0 and 4.3.1RC2 after re - generation.

Without the File - Filter DeltaWalker lists the differences:

...think that DeltaWalker will be a good helper and a great example for RCP Apps.

blog in german

Properties in OSGI Declarative Services and ServiceTracker

2008-12-04T20:23:00.015+01:00

As proposed in my last blog "Dependencies and Services in OSGI Enterprise Applications" it seems that a new blog series was started ;-)

ServiceTracker vs Declarative Services

There was only a short statement last time - now some tips follow how to use properties in ServiceTracker vs Declarative Services (DS).

A ServiceTracker from my OSGI Server project was opened with this Filter:

final String filterPool = "("

+Constants.OBJECTCLASS

+ "="

+ JDBCPoolComponent.class.getName()

+")";

So the ServiceTracker will get Services of Type JDBCPoolComponent - we are interested into the attribut JndiName:

private void processDataSources(JDBCPoolComponent service) {

if (service.getJndiName().equals("foo_entity_data_source_hsql")) {

// do something

}

How could this be done using Declarative Services (equinox.ds):

We're defining a reference to get exactly one specific service of type JDBCPoolComponent to know that a DataSource is ready.

A first idea to declare this reference could be:

Launching the OSGI application, but the reference wasn't resolved.

How could we find the reason ? At first we should test if the Filter is correct and there's no typo in the Interface.

Tip: Use of Equinox OSGI Console to test the Filter !

Try this command:

services (&(objectclass=org.ow2.easybeans.component.jdbcpool.JDBCPoolComponent)

(jndiName=foo_entity_data_source_hsql))

But no Service was found: No registered Services.

As next we try only to look for Services of Interface JDBCPoolComponent. Now our command looks like:

services (objectclass=org.ow2.easybeans.component.jdbcpool.JDBCPoolComponent)

Some Services were listet - we also see the one we're looking for:

{org.ow2.easybeans.component.jdbcpool.JDBCPoolComponent}={classname=org.ow2.easybeans.component.jdbcpo......, xmlconfig=

Registered by bundle: .../easybeans-component-jdbcpool_1.1.0-M3-SNAPSHOT.jar/

Analyzing the printed text we found: jndiName="foo_entity_data_source_hsql"

But there's a small difference: its the Property xmlconfig containing the informations. Thats the solution:

services (&(objectclass=org.ow2.easybeans.component.jdbcpool.JDBCPoolComponent)

(xmlconfig=*foo_entity_data_source_hsql*))

The Service we want to reference will be found and we know how to declare the reference inside the Service Component:

Why can the ServiceTracker use getJndiName(), but the target Filter can't ?

getJndiName() is a Methode of JDBCPoolComponent, but JndiName isn't registered as Service Property !

Target Filter cannot access methods of implementation - only Service Properties.

You maybe run into this using 3rdParty bundles where you have to live with their services as-is. If you're in luck its Open Source, you write a Bugzilla or JIRA and get it fixed in hours :-)

Remark:

You can take a look at my blog series about "OSGI Enterprise Applications" - the index is in the column right beside this blog.

There are also some submissions for EclipseCon 2009 - if you want to hear more about: comments are welcome ;-)

blog in german

Dependencies and Services in OSGI Enterprise Applications

2008-12-02T20:46:00.018+01:00

A busy week has started again:

Refactoring my OSGI Enterprise Server: Using Declarative Services instead of ServiceTracker where possible. (I'll report soon in my other blog series)
openArchitectureWare 4.3.1RC1 is published and has to be tested against my many modeling templates
Some more tests using Eclipse 3.5M3: PDE - supporting Declarative Services and Cycles in 3rd Party Bundles
Development of a new soon-coming project: redView (Riena - EMF - Dynamic Views) and integration of these dynamic view models into my modeling workflow

But now lets start and report some of my experiences of:

Dependencies and Services in OSGI Enterprise Applications

If you follow my blog series „HowTo Build an OSGI Enterprise Server“, you probably have read in the last entry that its difficult to use a ServiceTracker with much logic and dependencies inside. Its not so hard to make it run, but hard to manage all the dynamic of an OSGI application. So the next task is to use Declarative Services instead as possible to solve the requirements. While working in this area I noticed some points I want to blog about.

PDE Tooling

This is really the first what happens: you'll miss the comfortable PDE tooling.

You have to describe the service components in a XML file without support:

... and also an entry in the MANIFEST.MF as reference to this file:

Good news: Dopwnload and test Eclipse 3.5M3: PDE Tooling supports now Declarative Services :-)

Managing Dependencies

Under OSGI the management of dependencies is very important and fundamental to get a well structured application achitecture.

We already know dependencies using Import-Package or Require-Bundle. We can also look at these dependencies from inside eclipse.

The classic way as Plug-In - Dependencies:

or the easy to understand visuell way:

(here's the Updatesite from Graph Visualization Plug-In)

But bundle - dependencies are only one part - we're missing the service - dependencies.

If you look at the DataSource example from above:

There are no more bundle dependencies ? Indirectly we have dependencies from Declarative Services: The DataSourceService will only be provided if exactly one service of Type Ejb3ServerComponentsService and one service of type JDBCPoolComponent is available. These two referenced services are declared in two other bundles.

If our declarative Service Component would include bind / unbind methods, then we would have Import-Package dependencies.

Till now I couldn't find a tool displaying service - dependencies in a visual graph.

And if you think more about service - dependencies: there are some different strategies to use services and you can even mix them in one application:

Declarative Services
ServiceTracker
Riena-Service-Injection
...

As an Software Architekt I like to get an overview of used Bundles, Services and dependencies. Because there's no tool to show the existing dependencies I'll come the way from another direction: my server project is model-driven, so I can model service - dependencies and -strategies :-)

using openArchitectureWare I'll then generate service - components in XML - files or Javacode for ServiceTracker or Riena - Injection ...

This will be part of another blog ;-)

debug - trace - log Declarative Services

While refactoring my project of course from time to time I reached a point asking why a specific declarative service reference is not resolved from eqinox.ds ;-)

With the help from Equinox - Newsgroup and some searches I learned some important System Properties I didn't found in the Eclipse Help or Equinox Wiki:

equinox.ds.debug=true switch debugmode on
equinox.ds.print=true prints the trace-logs on the console. I dont need it because I catch the OSGI LogServices and log them by myself.(s.a. blog series Logging)
equinox.ds.perf=true logs the execution times in ms
equinox.scr.waitTimeOnBlock=10000 how many ms should equinox.ds wait until a service component is ready. Was very helpful because 10000 ms is default and some 3rdParty components need more then 50000 ms in DEBUG log - mode.

ServiceTracker vs Declarative Services

Can a Service Tracker completely be replaced by Declarative Services ? No - this isn't always possible.

One example: Using a ServiceTracker you can get access to all methods of a service - using Declarative Services instead you can only use service properties in target - filters.

...enough for the first blog about Declarative Services - there are so many things to talk about in this context, so I can imagine to start a blog series about this - but at first I have to finish the already started blog series ;-)

You can take a look at my blog series about OSGI Enterprise Applications - the index is in the column right beside this blog.

There are also some submissions for EclipseCon 2009 - if you want to hear more about: comments are welcome ;-)

blog in german

HowTo Build an OSGI Enterprise Server: EasybeansServiceTracker

2008-11-21T20:55:00.016+01:00

We've seen that its not easy to use EasyBeans OSGI - you have to be very carefully how to start bundles, watch many dependencies etc. So we created a „Server - Agent“ - bundle to control and manage these tasks.

This „Server - Agent“ - bundle contains an EasybeansServiceTracker we'll discuss now.

At first we must be sure that all EasyBeans Components are started - there's an easybeans.agent bundle controlling this. EasyBeans Components are:

Which of these EasyBeans Components you need depends from your reqirements - in this blog series we'll only look at the EJB3 Container.

One component is important in our use case: JDBCPool registers data sources as JNDI names and this must be done before EasyBeans can manage the "EJB - bundles".

If we're sure that all EZB Components are registered and also the JDBCPool Component has registered all data sources, then we can start our „PersistenceContext - Bundles“ and „EJB - Bundles“.

While creating an EJB3 - Container for each of our „PersistenceContext - Bundles“ and each of our „EJB - Bundles“ EasyBeans registers for each Business - Interface (@Local, @Remote) a ManagedService. The EasybeansServiceTracker tracks all Remote - Business - Interfaces and registers them as Riena Remote Endpoints.

When the EJB3 Container is completed from EasyBeans - an EZBContainerService will be registered. After checking that EZBContainerServices are registered for all of our EJB - Bundles we can register the RienaEasyBeansServerService: our Server it ready.

EasybeansServiceTracker

You'll have some logic like this in your Tracker:

Is the use of a ServiceTracker the best solution ?

At first it looks good to have all the logic around the EasyBeans EJB3Container at a central point in our EasybeansServiceTracker - and it works well.

Analyzing it in more detail you'll find out that its very complex and difficult to manage - even thinking on multi-threading. Also: does it look like the nature of a dynamic and flexible OSGI solution ? How to react if bundles or services are stopped and started again ?

But there's an alternative way: we'll look again how to solve the EJB3 - Container in our OSGI Enterprise Application using Declarative Services. Then you can decide what you prefer to use: ServiceTracker or Declarative Services.

There's an this index of this blog series in the column right beside the blog entries.

blog in german.

Going to Eclipse Summit

2008-11-17T18:03:00.004+01:00

Same procedure as every year going to Eclipse Summit or EclipseCon:

Because my OSGI Enterprise solution needs it all:

Equinox, OSGI, Riena, RCP, Modeling (oAW, EMF, UML), UI, PDE, P2, ....

...its so hard to decide which of the sessions to choose ;-)

I'll arrive Tuesday evening - so I can't go to the e4 and RT Symposium

Hope to see some of you in Ludwigsburg

ekke

HowTo Build an OSGI Enterprise Server: EJB3 Container

2008-11-17T13:11:00.015+01:00

This entry of my blog series „HowTo build an OSGI Enterprise Server“ will talk about the „EJB3 Container“ managed by EasyBeans. EasyBeans uses by default Felix as OSGI Framework - this blog series describes how to use it all under Eclipse Equinox together with Eclipse Riena.

You have to follow some rules how to start the OSGI application: start - levels, start - order, automatic-start ... Please read important instructions in chapter „Server starten“. A short overview:

Our OSGI Enterprise application automatically starts a „Server Agent - Bundle“ - this agent contains an OSGI Service Tracker watching if EasyBeans initializes all EJB3 Container to see when all is ready.

We also start our domain-specific „Server Bundles“ which are tracking to see if our ServerService is registered from „Server Agent“ Bundle.

Server - Agent - Bundle and Server - Bundles

Our (domain-specific) „Server - Bundles“ and the „Server - Agent - Bundle“ are started automatically using Default - Start - Level (in our example Level 3).

The „Server - Bundles“ are waiting until a RienaEasyBeansServerService signals, that our Server with Riena- and EasyBeans - Functionality is available.

The most important dependencies of our „Server - Agent“ - Bundle:

The „Server - Agent“

tracks Services from EasyBeans using an EasybeansServiceTracker
registers Remote - „Business - Interfaces“ for Riena - Remoting
registers RienaEasyBeansServerService when or server is available

EasybeansServiceTracker - Filter

An OSGI ServiceTracker should only track needed Services - so we have to define a Filter used as Parameter creating a new ServiceTracker. The Filter:

(|(objectClass=org.osgi.service.cm.ManagedServiceFactory)(objectClass=org.ow2.easybeans.api.EZBContainer)(objectClass=org.ow2.easybeans.component.jdbcpool.JDBCPoolComponent)(service.pid=*RemoteManagerI*Bean))

What kind of OSGI Services we'll get using this Filter ?

ManagedServiceFactory:

EasyBeans registers for each EasyBeans Component a Service of Type ManagedServiceFactory:

{org.osgi.service.cm.ManagedServiceFactory}=
{service.pid=org.ow2.easybeans.component.carol.carolcomponent,..
Registered by bundle:
...easyBeans/bundles/easybeans-component-carol_1.1.0-...jar
Bundles using service:
.../org.eclipse.equinox.cm_1.0.0.v20080509-1800.jar
.../org.ekkehard.server.agent_1.0.0.jar

Tracking these Services we can test if all EasyBeans Components are correct initialized.

EZBContainer:

After successfully processing our „EJB - Bundles“ and „PersistenceContext - Bundles“ from EasyBeans a Service of Type EZBContainer is registered:

{org.ow2.easybeans.api.EZBContainer}={service.id=103}
Registered by bundle: .../org.ekkehard.foo.datamanager.bean_1.0.0.jar
Bundles using service:
.../easybeans-core_1.1.0-M3-SNAPSHOT.jar
.../org.ekkehard.server.agent_1.0.0.jar

Tracking these Services we know, that EasyBeans has created an EJB3Container for our Bundle - and if its a „PersistenceContext - Bundle“ then we also know, that Hibernate has done all the Mapping and Binding.

JDBCPoolComponent:

EasyBeans JDBCPoolComponent registers always after initializing a DataSource an OSGI Service of Type JDBCPoolComponent:

{org.ow2.easybeans.component.api.EZBComponent,
org.ow2.easybeans.component.jdbcpool.JDBCPoolComponent}=
{... jndiName="foo_data_source_hsql"....

Using the Property jndiName we can test if our DataSource is available.

service.pid:

We also filter Services containing a service.pid of our pattern for Remote - Business - Interfaces: „*RemoteManagerI*Bean“. The pattern depends from your naming schema.

Tracking those Services will give us OSGI Services of Type ManagedService. The we do some additional testing to see if some Properties are set from EasyBeans. If true, we know that its a ManagedService created by EasyBeans for one of our @Remote - „Business - Interfaces“.

Now we can register this @Remote - „Business - Interface“ for Riena Remoting, to provide a Riena Published Endpoint for our Rich Clients.

This is also the reason why the „Server - Agent - Bundle“ needs Package-Import-Dependencies to our „Business - Interface - Bundles“ - if you dont use Riena, then you dont need these dependencies.

RienaEasyBeansServerService

If all tracking was successfully, then our „Server - Agent - Bundle“ registers an RienaEasyBeansServerService as OSGI Service. Because this Service will also be registered as Riena Remote Endpoint, our „Server - Bundles“ and also our „Rich Client - Bundles“ can track if the Server of a specific domain is live and ready-to-go.

When knows the „Server - Agent“ that all was successfully processed ?

All EasyBeans Components are initialized
All DataSources are avilable
All EJB Container are available

There are some special tricks how to track and test and start bundles - but this will be part of the next blog.

There's an this index of this blog series in the column right beside the blog entries.

blog in german

HowTo Build an OSGI Enterprise Server: Entity- and EJB- Bundles

2008-11-12T20:58:00.012+01:00

This part of the blog series „HowTo build an OSGI Enterprise Server“ will take a look at the different types of bundles we provide to the EJB3 container. The next chapter „EJB3 Container“ will show you how to use an OSGI ServiceTracker to start and initialize all the right way.

How to divide Entities and EJBs in Bundles

BTW: you should have knowledge about EJB3 and Annotations. The structure used in this server is only an example and your implementation perhaps is different. We can talk about these issues later after publishing source code. Also you can use Eclipse Link as JPA provider instead of Hibernate - EasyBeans can work with both.

We're using following types of bundles:

Entity - Bundles
EJB - Bundles
PersistenceContext - Bundles
Business Interface - Bundles

Entity - Bundles

@Entity, @Embeddable

You can use as much Entity - Bundles as you want - perhaps structured vertical for your different domains. These Entity - Bundles will also be used from our Rich Client, so - if you have bundle dependencies only used at server-side, make them optional.

EJB - Bundles

@Stateless and @Stateful Beans, implementing Business - Interfaces (@Local, @Remote) depending from your requirements.

These Bundles have dependencies to your Entity - Bundles and to the Business - Interfaces.

Other EJBs from your PersistenceContext - Bundles can be injected like:

@EJB(mappedName) Business - Interface

The EJB - Bundles will not be used from Rich Client.

Remark: mappedName must be used at the moment, EZB cannot found the corresponding Business - Interfaces, if they are in different bundles (JIRA EZB-322)

PersistenceContext - Bundles

@Stateless Beans, containing a PersistenceContext (EntityManager) and - depending from your use-cases - implementing Business - Interfaces (@Local, @Remote).

@PersistenceContext(unit-name) points to your Persistence - Unit.

Each PersistenceContext - Bundle has a persistence.xml with attributes for the persistence-unit and also jta-data-source.

PersistenceContext - Bundles need package-imports of the used Entities and implemented Business - Interfaces.

PersistenceContext - Bundles will not be used at Client-Side.

Remarks:

All EJBs, belonging to a peristence-unit, must be in ONE bundle at the moment. (JIRA EZB-294)
The Beans must have an EJB3.mappedName attribute: @Stateless(mappedName), otherwise because of a bug from EasyBeans (JIRA EZB-322) injected @EJB won't found them.
Inside the persistence.xml all Entity- and Embeddable must be listed as class entries. EasyBeans should found the classes itself because of Annotations, but there's a bug if Entities and EJBs are in different Bundles.

Business Interface - Bundles

@Local, @Remote

The Business - Interface - Bundles can be structured and separated as you want - perhaps for different sub-applications or domains or...

These Bundles will also be used from your Rich Client.

EasyBeans Configuration

EasyBeans needs some configuration - data. If you're using an OSGI Framework Configuration you can add a VM argument:

-Dorg.ow2.easybeans.osgi.conf.dir=${workspace_loc}/config/easybeans/config

In this config folder you must store the easybeans.xml.

This easybeans.xml contains jdbcpool jndiName entries for each of your Data - Sources. These values are identical with the jta-data-source, described at your Persistence Unit inside persistence.xml of our PersistenceContext - Bundles.

Remark: The EasyBeans JDBCPool - Component must register first all Data - Sources, before you can start your PersistenceContext - Bundles. s.a. chapter „EJB3 Container“ for details on this.

openArchitectureWare - always can help if you're in trouble

This project is model-driven - details about it will be described in another blog series. Here are some small examples showing you, why I never will miss openArchitectureWare in a project lead by me.

EasyBeans should recognize @Entity and @Embeddable automagically because of annotations - but it doesnt work through borders of bundles, so all @Entity and @Embeddable - classes have to be listed in your persistence.xml - in my ERP project this means more then 800 classen - and the data model isn't static and grows or changes depending from new use-cases and requirements.

But thanks to openArchitectureWare (oAW) we only need some lines in a template to get the needed output into the persistence.xml:

automatically all was generated from oAW and is in sync with your entity data model:

Another example: EasyBeans should be able to inject @EJB MyBusinessInterface correctly. But because of a bug this isn't possible if Business Interfaces are in another bundle and so we need the @EJB.mappedName attribute.

But with oAW its also easy: insert some text into a XPand - Template to add this attribute:

... and in your Business Interface:

Now all Beans get the mappedName attribute, the Business Interfaces get a Constant with this mappedName so you can inject easy:

@EJB(mappedName = MyInterface.EZB_MAPPED_NAME) MyInterface mi = null;

These are positive side-effects of model-driven development: developing of workarounds in hundredrs of classes are funny ;-)

BTW: my whole complex ERP - project would not be possible to be realized from me alone without oAW. You'll hear more about this in another blog series - and of course its your decision if you work model-driven or not - I only can show you my way of working.

blog in german.

HowTo Build An OSGI Enterprise Server: Introduction

2008-11-11T13:17:00.009+01:00

If you followed my blog series „Logging in OSGI Enterprise Applications“, you probably know that logging is only one small but important aspect of an OSGI Enterprise Server.

This new blog series „HowTo Build An OSGI Enterprise Server“ will give you tips from my experiences how to build and configure an OSGI server, how to structure your project and bundles and how to make it all run.

Main parts of the server are:

Equinox (OSGI Framework)
Riena (OSGI RemoteServices, ObjectTransactions)
EasyBeans (OSGI EJB3 Container, Hibernate JPA)

There will also be a rich client:

Equinox (OSGI Framework)
Eclipse RCP
Riena (OSGI RemoteServices, ObjectTransactions, UI: Ridgets)

(Clients for mobile devices and web will follow.)

Not only the Runtime Platform is important - the whole project is model-driven:

Eclipse Modeling (EMF, UML2)
openArchitectureWare - oAW (Workflow, XPand, Xtend)
Magicdraw (UML, DSL, oAW Integration)

Server, Client, oAW Templates, MagicDraw Custom DSL Editor will be published as Open Source (EPL) and are used as core of an ERP - Business Solution.

Before giving an overview of the project and then start with chapter „Installation“ I'll jump to chapter „EasyBeans as OSGI EJB3 Container integrated with Equinox“ because I know some are waiting for this.

From readers of my last blog series I learned that its not always easy to read the entries in right order - to help you I'll always update an index of the blog series. You'll find this index in the column right beside the blog entries.

I hope to help some others with this new blog series and I'm always thankful for your feedback.

Later on blog series will follow "HowTo build an OSGI Rich Client" and also "Modeling OSGI Client - Server Applications".

blog in german.

Index BlogSeries Logging in OSGI Enterprise Applications

2008-10-31T15:54:00.003+01:00

I got responses that its not easy to read the blog series

"Logging in OSGI Enterprise Applications" in chronological order.

So here's the index:

Part 1: An overview
Part 2: How to catch all log events from "classic" logging - frameworks
Part 3: How to catch all log events from OSGI Log Services
Part 4: How to start logging bundles the right way inside an OSGI Enterprise application
Part 5: Configuration, Fragment-Bundles, Markers

...more will follow

ekke

Logging in OSGI Enterprise Applications, Part 5

2008-10-31T07:38:00.028+01:00

This (fifth) part of my blog series "Logging in OSGI Enterprise Applications" will show you some important elements of configuring the logging framework LOGBack we use as SLF4J implementation:

I dont want to talk about the configuration of a logging framework itself - you should be familiar with this. If you're using LOGBack inside an OSGI Enterprise Application there are some special things to watch and problems to solve.

If we're logging in a non-OSGI Java Application we normaly want to know which class logs the event. Logging from an OSGI Enterprise Application its also important to know which bundle causes the LogEvent. Using OSGI LogServices you also have this information from BundleContext..

Its a good practice to name the Logger with the class name - normaly as static Logger defined in each class. This works with all logging frameworks like Log4J, Commons-Logging, java.util.logging or SLF4J.

Using SLF4J as Logging API you can also describe the source of the Log Event more detailed with:

MDC (Mapped Diagnostic Contexts)
Marker

MDC is implemented by Log4J and LOGBack. MDC is great to store informations from a client user session: per ex. Username, IP etc. Its a Map and you're free to store what you like. To access these informations in the Layout of an Appender is easy:

...N:%X{username}...

produces

...N:JohnDoe...

The LOGBack User Manual chapter 7 (here) explains it in detail and gives you some examples.

Marker and Bundles

Marker are part of the SLF4J API and they mark (as the name says ;-) Log Messages. At the moment only LOGBack implements Marker.

From the MarkerFactory for a given String we always get the same Marker:

Marker marker = MarkerFactory.getMarker("MyMarker");

Marker can reference other Marker - so you can build an object graph of Marker:

Marker special = MarkerFactory.getMarker("special");

special.add(MarkerFactory.getMarker("init"))

In our OSGI Enterprise Application we're using Marker to log the Name of the bundle.

For each bundle we define once (per ex. in the Activator):

private static final Logger logger = LoggerFactory.getLogger(MyActivator.class);

public static final String ID = "my.bundle.symbolic.name";

public static final Marker bundleMarker = createBundleMarker();

private static final Marker createBundleMarker() {

Marker bundleMarker = MarkerFactory.getMarker(ID);

bundleMarker.add(MarkerFactory.getMarker("IS_MARKER"));

return bundleMarker;

}

In all the other classes of a bundle we define:

import static MyActivator.bundleMarker;

private static final Logger logger = LoggerFactory.getLogger(Foo.class);

Then the logging statements are looking like:

logger.debug(bundleMarker,"This is my {} message",xyz);

Remark: LOGBack replaces {} with xyz. toString(). More details later.

To get the marker in the logging - output we can simply use

... %marker ...

in the Layout of an Appender.

In our application we want to test if a Marker is a BundleMarker and then handle formatting the output different, per ex.:

... - [B:my.symbolic.bundle.name] ...

To do this we have to extend ch.qos.logback.classic.pattern.ClassicConverter and overwrite the methode public String convert(LoggingEvent le).

In our LOGBack configuration (logback.xml or logback-test.xml) we have to insert a new ConversionRule:

then we can use it in the Layout of an Appender:

... %bundle ...

and we get as output

... - [B:my.symbolic.bundle.name] ...

or an empty String if the Marker is no BundleMarker.

Fragment Bundles

But thats not all - because the logback.classic Bundle doesnt know our BundleConverter class we need a Fragment-Bundle:

You remember: We already use another Fragment to use our configuration file from Logback Core Bundle:

Remark: perhaps you have noticed that the Manifest files above are using logback Version 0.9.11: there are new versions of SLF4J (Download Version 1.5.5) and LOGBack (Download Version 0.9.11). Because at the moment they are not found from SpringSource EnterpriseBundleRepository we have to build them by ourself. How to do this is explained in part 2 of this blog series.

Logoutput twice

It looks so good: we catch all LogEvents from all Logging Frameworks used from other Bundles and also from OSGI LogServices. But it can happen that you found some messages twice in your log output. What happens ? If you're using per ex. Eclipse Riena M4 you got messages twice:

Riena uses Listener to catch OSGI Logservices and logs them using Log4J. Log4J will found the way to our SLF4J / LOGBack implementation. So long so good.

But our own Logging Bundle org.ekkehard.osgi.over.slf4j also catches OSGI Logservices and loggs them using SLF4J / LOGBack.

And now we got some messages twice.

The good news first: in some days Riena will publish Milestone M5 and then you should be able to switch these Listeners from Riena-Logging off.

Because it can happen every day again using other 3rdParty bundles, here's the solution. We need an entry in our LOGBack configuration file logback.xml:

This will hide those output from org.eclipse.riena.

Riena uses Equinox Extended OSGI Logservices, which contain an own Logger. We catch those ExtendedLogEvents and log the message using the Loggername from ExtendedLogEntry. To distinguish Logging - Output from our Listeners we add a prefix:

Now we know where the Logging - Output comes from and as a side-effect its easy to log all LogEvents originally logged from Equinox ExtendedLogServices per ex. at DEBUG Level:

Here's an example logging output catched by our Listener and logged to LOGBack:

23:25:41.846 DEBUG [X.o.e.r.c.publisher.ServicePublishBinder] - [B:org.eclipse.riena.core] service endpoints count: 792

ExtendedLogEntry uses this as Loggername:

org.eclipse.riena.communication.publisher.ServicePublishBinder

We add the prefix "X."

You also see a Bundlename (from our BundleConverter)

org.eclipse.riena.core

We got the name from Context of the catched ExtendedLogEntry:

getBundle().getSymbolicName()

Using Marker from LOGBack is an easy way to get the information of the Bundle logging the event and also not to loose the Bundlename if rooting LogEvents from OSGI LogServices to SLF4J/LOGBack.

What happens next ?

This blog series isn't finished, but we already talked about the most important informations about Logging in OSGI Enterprise Applications. Of course I'll continue this series next months because there are some more aspects to look at in detail. But expect next blog entries in a time-frame of 2-3 weeks for each.

Blog Series "Logging in OSGI Enterprise Applications":

Part 1: An overview
Part 2: How to catch all log events from "classic" logging - frameworks
Part 3: How to catch all log events from OSGI Log Services
Part 4: How to start logging bundles the right way inside an OSGI Enterprise application
Part 5: Configuration, Fragment-Bundles, Markers
Part 6: ... follows (Stay tuned...)

Perhaps some of my older blogs about Logging und OSGI are also interesting:

New blog series coming soon

Now I'll also starting a new blog series :

„HowTo build an Equinox-Riena-EasyBeans-OSGI-Server“.

After working through that blog series you'll get a complete server as Open Source (EPL) to try it out by yourself. This server of course also contains all of the logging aspects I talked about.

this blog in german

Logging in OSGI Enterprise Applications, Part 4

2008-10-20T00:05:00.013+02:00

Part 4 will demonstrate how to start the logging - framework and all the bridges inside an OSGI Enterprise Application.

To remember: At the end of the last (third) part of my blog - series "Logging in OSGI Enterprise Applications" we were able to log all events from „classic“ log-frameworks, OSGI LogServices, BundleEvents and FrameworkEvents using a SLF4J Log - implementation (LOGBack):

If we want to use it all inside a complex OSGI Enterprise Application its important to start the bundles using the right start-level. We also have to decide which bundles can be auto-started from the framework and which not.

As an example I'll use again my OSGI - Equinox - Riena - EasyBeans - Hibernate - Server. I'll talk in detail about this server later in one of the follow-ups.

From OSGI Launch Configuration:

Default Start - Level is set to 3.

Our osgi-over-slf4j - Bundle must be started before (Start-Level = 2) and the EasyBeans - Agent - Bundle later (Start-Level = 4)

We also have to watch that some bundles cannot be started with Auto-Start = true ! These bundles will be started under control from EasyBeans Agent bundle.

What happens now starting the OSGI server application ?

The OSGI - Framework Equinox will be started
Our org.ekkehard.osgi.over.slf4j bundle will be started. The Activator calls in the start() method SLF4JBridgeHandler.install() to catch all log - events from java.util.logging - also the Activator contains Logger - Statements. All this causes starting and activating SLF4J - API and SLF4J - implementation (LOGBack) - bundles: our Logging Framework is alive !
All bundles with Auto-Start = true will be started then from the Framework. This includes all Eclipse Riena bundles. Riena uses LOG4J - so the LOG4J - bridge will be started. Riena also uses Equinox - Extended - OSGI - Log - Services.
After starting all Default - Start - Level - bundles, the easybeans.agent will be started. This agent starts all EasyBeans components and Hibernate. EasyBeans uses Commons - Logging and java.util.logging - Hibernate uses SLF4J. Then all our logging - framework - bridges are started and active. EasyBeans then starts all Entity - bundles and EJB3 - bundles from our server and registers the EJB3 - Business - Interfaces (Local oder Remote) als OSGI - Services.
The org.ekkehard.server bundle tracks OSGI Managed Services and recognizes, when all required services are configured from EasyBeans and Hibernate and ready-to-go. Then org.ekkehard.server registers Services as Remote Services for Eclipse Riena.

Remark: This is only a small part of all the activities and tasks happening while starting the server. More about 4. and 5. later in another blog series. Lets first finishing the logging.

No black holes ?

If we did it all well, then our SLF4J - Implementation LOGBack should start so early that we get all log - events and nothing is lost in space.

To test this we configure our logback-test.xml as follows: set Root Level to DEBUG, output to Console, swich DEBUG - Mode of the configuration itself on and start the server.

You should get a log like this:

Line 1: equinox - osgi - Console
Line 2 - 7: Debug-output from LOGBack configuration
Line 8 - 9: Logging-output from osgi-over-slf4j - bundle

There's no other logging-output on the console before starting SLF4J / LOGBack :-)

The next blog will look at the configuration of LOGBack and some special Fragment - Bundles for configuration and also extending the LOGBack - implementation.

Part 1: An overview
Part 2: How to catch all log events from "classic" logging - frameworks
Part 3: How to catch all log events from OSGI Log Services
Part 4: How to start logging bundles the right way inside an OSGI Enterprise application
Part 5: ... follows (Stay tuned...)

Perhaps some of my older blogs about Logging und OSGI are also interesting:

the blog in german.

Logging in OSGI Enterprise Applications, Part 3

2008-10-11T15:55:00.034+02:00

Part 3 explains how to catch all log events logged by OSGI Bundles using OSGI Log Services.

In part 2 you've seen that catching log entries from "classic" Log - Frameworks was very easy:

✓ Choose the right bundles
✓ Create a config - file

-thats all :-)

Remark: java.util.logging needs also this one-liner: SLF4JBridgeHandler.install();

Running an OSGI Enterprise Application you'll also find bundles logging their log - entries using OSGI Services:

org.osgi.service.log.LogService
org.osgi.service.log.LogReaderService

You have also to watch for Services extending the "normal" OSGI Log Services: Eclipse Riena per ex. uses from Equinox Incubator:

org.eclipse.equinox.log.ExtendedLogService
org.eclipse.equinox.log.ExtendedLogReaderService

You can read Log entries using the LogReaderService. You only have to register your LogListener.

The LogListener gets all LogEntry (ExtendedLogEntry), then you can log them using SLF4J-API to your LOGBack Implementation.

You have to use the same config file (logback.xml or logback-test.xml) as described in part 2 (logging the entries from „classic“ Log - frameworks). Details about configuration will follow in another Blog of this series.

Short overview:

We already have following bundles used as bridges between „classic“ Log-Frameworks and SLF4J / LOGBack:

slf4j.api
jul.to.slf4j
log4j.over.slf4j
jcl.over.slf4j

There are also the bundles of the SLF4J - implementation LOGBack:

logback.core
logback.classic

You'll find more details in part 2 of this Blog series.

Bundle osgi.over.slf4j (a bridge between OSGI Service and LOG4J)

We need a bundle as bridge between OSGI Log Services and SLF4J / LOGBack. Please create a Plug-In project using PDE:

my.namespace.osgi.over.slf4j

Your MANIFEST.MF should look like:

This osgi.over.slf4j - bundle has its own org.slf4j.Logger:

We'll use this Logger to log events from this bundle itself and also to log all catched LogEntry from other bundles.

To track LogReader Services we can use a ServiceTracker:

We create our LogServiceTracker with this filter to get only services from type LogReaderService or ExtendedLogReaderService:

(|(objectClass=org.osgi.service.log.LogReaderService) (objectClass=org.eclipse.equinox.log.ExtendedLogReaderService))

A LogListener for „normal“ OSGI LogServices:

LogEntry will be logged using the Logger of our osgi.over.slf4j - bundle.

A LogListener for „extended“ Equinox OSGI LogServices:

ExtendedLogEntry already contains an own Logger.

We'll use an org.slf4j.Logger with same name - but to distinguish we use a prefix („X.“). Details will follow in another Blog.

Then we delegate LogEntry and ExtendedLogEntry to the org.slf4j.Logger:

We have to map the OSGI LogService Levels. We can get the origin message and (optional) exception from LogEntry and delegate to our Logger.

Different from Log4J or Commons-Logging is using a Marker. Markers are part of the SLF4J API, but at the moment only the LOGBack - implementation uses them. We are using Marker to print the bundle-name and perhaps also the service-name. Then we know which bundle / service originally creates the LogEntry or ExtendedLogEntry.

Remark: More about Marker you'll find in one of the next Blogs of this series.

Logging BundleEvent and FrameworkEvent

Its a good idea also to log org.osgi.framework.BundleEvent and org.osgi.framework.FrameworkEvent.

To do this we need these Listener:

Dependent from the Event - Type we create the message and level.

Remark: More about SLF4J - Marker in one of the follow-ups.

--------------------------------------------------------------------------------

Now we are ready to catch and log all events from „classic“ Log-Frameworks, OSGI LogServices, BundleEvents or FrameworkEvents using SLF4J / LOGBack:

This was the third part of my blog series "Logging in OSGI Enterprise Applications":

Part 1: An overview
Part 2: How to catch all log events from "classic" logging - frameworks
Part 3: How to catch all log events from OSGI Log Services
Part 4: ... follows (Stay tuned...)

Perhaps some of my older blogs about Logging und OSGI are also interesting:

the blog in german.

Logging in OSGI Enterprise Applications, Part 1

2008-09-24T17:42:00.030+02:00

Logging is an important part of ERP Applications and should be easy using a modern logging framework ;-)

My actual work-in-progress (german ERP solution) contains: Equinox as OSGI Framework, Eclipse Riena for Remote Services + UI, EasyBeans as EJB3 Container + JPA (Hibernate) etc.

This means I have to integrate different logging - frameworks:

org.osgi.service.log
org.eclipse.equinox.log (Extended Log Services from 1.1.0.HEAD)
org.apache.commons.logging
org.apache.log4j
org.slf4j
java.util.logging (JSR47)

If you already followed some of my blogs, then you probably know that its not easy to design a clean OSGI architecture for a complex business application.

Actually I was confronted with the newest snapshot of EasyBeans containing a new Hibernate release (3.4) now using SLF4 as logging framework. This causes me to rethink my logging architecture.

The logging solution should make my OSGI client / server - application independent from logging frameworks. I'll explain all in detail later. At first I'll give you an overview to see the differences between "classic" Java logging frameworks and OSGI Logging Services.

"Classic" Java Logging Frameworks

Apache Commons - Logging (JCL)
Log4J - Logging
SLF4J - Logging
JDK - Logging (java.util.logging)

Usually logging works this way:

Logger definition:

Commons-Logging:

private static Log logger = LogFactory.getLog(MyClass.class);

Log4J:

private static Logger logger = Logger.getLogger(MyClass.class.getName());

SLF4J:

private static Logger logger = LoggerFactory.getLogger(MyClass.class);

JDK:

private static Logger logger = Logger.getLogger(MyClass.class.getName());

Logging a message:

logger.info(„my message“)

Because concatenating Strings is slowly we also find:

if (logger.isDebugEnabled())

logger.debug("message part 1" + aVar

+ "message part 2");

Remark: If you're using SLF4J (FAQ) in many cases you can simple use a parameterized message string:

logger.debug("message part 1 {} message part 2", aVar);

Configuring logging - frameworks:

Configuration can be made using Java code - but mostly you'll find a configuration file - wether in properties or XML format.

Whats different if you're using these logging frameworks under OSGI ?

you need a bundle for each JAR. You can find bundles for Commons-Logging, LOG4J and SLF4J partly in Eclipse or get them from a bundle repository
logging itself is the same as in normal Java applications
you have to place the configuration file into a Fragment-Bundle

OSGI Logging Services

Under OSGI you can use Logging Services:

Standard OSGI : org.osgi.log (OSGI Logging, implemented by org.equinox.log)
Extended: org.equinox.log (1.1.0.HEAD Version from CVS or Riena download), extended Logging)

OSGI Logging uses Services and Listeners. Equinox implements OSGI Log Services as ManagementServices.

LogService or ExtendedLogService - writes all log messages
LogReaderService or ExtendedLogReaderService - where you can read log messages from
LogListener - gets the messages from ReaderService and you can handle them

OSGI LogService can be compared with the Logger from "classic" Java logging. Its a good idea to place LogService Logger objects into the Activator of a bundle.

LogService logger = ...

Logging a message is nearly the same as logging in non - OSGI environments - of course we have to test if the service is available:

if (logger != null) {

logger.log(LogService.LOG_INFO, „my message“);

}

The LogEvent can then be read using the LogReaderService. You can "track" this ReaderService and add your own LogListener. This LogListener gets all messages and you can persist the messages or print to console or use one of the "classic" logging frameworks.

Equinox allows you to configure how many messages should be cached from LogReader Service and at which Log Level. But important to know: The LogReaderService sends always all messages to all registered LogListener independent from your configuration !

"Classic" Logging or OSGI Log Services ?

Lets look at the differences between "classic" Java - logging und OSGI - Log Services:

a) Which messages will be logged - and when ?

"Classic" Logging only creates log - messages if the Logger answers "yes" to „should I really log this message at those level for 'the.logger.name'“ ? It depends from the content of your configuration file, what you want to log at which level. If the Logger answers "no" - nothing will be logged.

OSGI Log Services always log ALL messages. The Log Reader Service gets them ALL. The Log Reader Service will inform all Log Listeners about all logged messages. Also the Log Reader Service will cache a configurable amount of messages.

The main task of a Log Listener is to filter the messages and to persist or print them.

b) What will be logged ? And whats the content of the Log Messages

Here you'll see the most important content of a Log Entry:

The different logging frameworks are also using different Log Levels, so they have to be mapped.

The logged Message is a String or will be created from myObject.toString().

MDC (Mapped Diagnostic Context) - a Thread - local Map where you can store context informations, per ex. user info of client sessions.

Marker - a tree of Strings you can mark messages with.

In an OSGI environment its very useful to log informations about the Bundle (and perhaps the Service Reference) where the logged message comes from.

Using OSGI Log Services you'll get this for free. If you're using SLF4J / LOGBack you can also store Bundle- and Service Names. (Using the Marker - more about this later)

c) Whats the best to use ? "Classic" Logging Frameworks or OSGI Log Services ?

Don't ask this question if you're developing an OSGI Enterprise - Application ;-)

Why not ?

You'll never know in advance, which (foreign) projects you'll have to integrate while the whole life-cycle of your business application.
You have to live with 3rdParty Bundles using all kind of logging - frameworks and -strategies. (Sometimes they change it as with Hibernate happened)

But you have to find the answer, HOW to combine and integrate them all without loosing flexibility. If you've solved this issue, then it also doesn't matter what you're using in your own bundles, because your logging architecture consumes it all :-)

Perhaps specific use cases can force you to use 'classic' logging and OSGI Log Services.

Integration of all Logging Frameworks and Log Services

The heart of my solution is SLF4J with LOGBack as native implementation.

SLF4J (Logback) has already bridges for all 'classic' logging frameworks: this enables you to use bundles logging to Commons-Logging (JCL), Log4J, JDK (java.util.logging) or SLF4J. All logged messages will be transparently routed to LOGBack.

Also all OSGI LogServices - wether Standard or Extended - will be catched from Log Listeners and delegated to SLF4J (LOGBack) delegiert.

So you have ONE place to handle all your logging :-) It depends only from your configuration, if LOGBack prints messages to Console or sends them to a socket (local or remote), to your filesystem, RDBMS or to a LogServer or ...

(Logging) - Integration of Eclipse Riena

If you're using Eclipse Riena M4 there are currently two small problems to solve:

1. Log4J-over-SLF4J

The bridge Log4J-over-SLF4J only provides the package org.apache.log4j, but org.eclipse.riena.core has a dependency to org.apache.log4j.xml. Please change this to "optional" in the MANIFEST.MF:

Import-Package: org.apache.log4j,

org.apache.log4j.xml;resolution:=optional,

org.osgi.framework;version="1.3.0",

org.osgi.service.cm;version="1.2.0",

org.osgi.service.log;version="1.3.0"

2. multiple log entries

Starting with M5 Riena's logging can be configured and its promised that you can switch it all OFF. While using M4 you'll notice two extra messages printed from Rienas LogListener to Console. (Bugzilla 247680)

(Logging) - Integration of EasyBeans OSGI

EasyBeans logging is now transparently routed to LOGBack without any problems. Since some days the Snapshots of EasyBeans 1.1.0 includes Hibernate 3.4, which itself now is using SLF4J. This also causes no problems because LOGBack is native Implementation of SLF4J.

additional informations

This blog is only the first one of a serie about Logging and OSGI. Perhaps it makes sense that you also take a look at my (older) blogs to know the hard way I went ;-)

Links:

Simple Logging Facade for Java (SLF4J)
LOGBack - Loggingframework, native SLF4J implementation
Eclipse Riena (Remote Services, UI enhancements)
Eclipse Equinox (OSGI Framework)
EasyBeans OSGI (EJB3 Container as OSGI bundles)
Hibernate (JPA - integrated into EasyBeans)

How goes it on ?

This blog is only part 1 of the series „Logging in OSGI Enterprise Applications“ giving only a short overview - the following themes will be later discussed in detail with source codee examples - so stay tuned.

HowTo registrier OSGI Logging Services
Tracking (standard and extended) OSGI Logging Reader Services
Adding Log Listeners to LogReader Services
HowTo configure LOGBack for OSGI
Mapping of LogLevels
Details of used Bundles, Manifest - files, dependencies,...
Fragment-Bundles
OSGI Launch configurations
Testing the whole stuff
Use of EasyBeans JDBC Pooling to persist messages from LOGBack in RDBMS
Performance issues (frameworks, "classic" logging vs. OSGI LogServices)
HowTo migrate existing code
Useful Eclipse PlugIns (Log4E, LogBack Console)
Client-/Server Logging Strategy, Remote Services, MDC - Userinfo...
The „black hole“: how to log before the services are ready ?
Use of SLF4J Marker to put Bundle- und Service - informations into
What happens if other bundles are also using Log Listeners and log messages ?
...

Remark: In my article I'm not covering PAX OSGI Logging. PAX uses Log4J as implementation and also integrates some logging frameworks (JCL, JDK, SLF4J, Avalon). Perhaps you should also take a look at PAX before deciding how to use logging in your OSGI application.

A more detailed complete article is already in work about „Logging in OSGI Enterprise Applications“ - and I'll continue this blog series.

Examples with sourcecode will also follow - I'm jst preparing a sample of my Equinox -based Riena-Easybeans-Server, where the logging of course is an important aspect.

Hopefully you can get some ideas from my experiences and ideas how to solve the logging problem. I promise: if you're developing OSGI enterprise applications - one day you'll run into logging problems, so its better you're prepared.

in german.

Eclipse Projects + OSX - some Tips

2008-09-14T12:42:00.006+02:00

More and more developers are using eclipse under OSX. Here are two tips from my current experiences:

1. Never name an Eclipse Project *.service

A project name like my.namespace.something.service causes OSX to think its an OSX service and the Finder will show it as an OSX Service and not as folder:

Using right-mouse-click you can look into the "package":

Last months it happens sometimes, that my *.service projects suddenly contain only 0 Bytes and the projects were empty. So I renamed all those projects.

2..DS_Store can confuse P2

Using the Finder of OSX to view folders and files from Eclipse installations causes the Finder to create .DS_Store files.

Suddenly I got on error while starting Eclipse (Bugzilla 247177). Reason was an unexpected .DS_Store file.

Using this command you can remove all .DS_Store files from a whole folder hierarchy:

find . -name *.DS_Store -type f -exec rm {} \;

(Its always a good idea on OSX to make „.“ - Systemfiles visible, because many important Eclipse files start with „.“: .project, .classpath, ...)

blog in german

PDE and MDSD [problem generated code and nested src]

2008-09-11T15:56:00.012+02:00

Its a good practice in a model-driven project to separate generated code from manually written code. (Generated code normaly will not be in your cvs / svn)

Eclipse Modeling and openArchitectureWare makes this easy: you can define different outlets in your workflow and XPand templates for generated code. manual code, resources etc.

As result you get a Plug-In Project with some nested src - folders. This is no problem for the Eclipse Java Compiler.

If you try to Export PDE - as deployable Plug-In you run into an error:

Errordialog:

Logfile:

PDE cannot export Plug-In projects with nested src folders. (s.a. Bugzilla with a small example project from me 241830)

Workarounds:

Before PDE - Exporting copy the Plug-In Project into a temporary second Plug-In and merge all src - folders into the one and only /src root folder. (Now the workflow while developing and testing isn't as easy as before)
Instead of PDE Export you can use a normal Java - Export as JAR (Loosing the comfort from PDE to auto-detect the Manifest file, versioning ....)
Create some ANT Tasks...

But I'm still looking for the pure PDE solution. Perhaps anyone has an idea how to make PDE happy with nested src folders ?

blog in german

PDE Target Platform - Rename Bundles [OSX]

2008-09-11T12:46:00.015+02:00

Sometimes we have to add "foreign" bundles to our Target Platform where the filenames are not conform to usual Eclipse naming conventions. EasyBeans per ex. uses a minus („-“) to separate the version-number where Eclipse uses Underline („_“).

Problems using „-“ in Symbolic Names are fixed for Eclipse 3.4.1 (Bugzilla 197503). Equinox has no real problems with bundle - filenames separating versions with "-", but its a good idea to rename them.

If you're using plug-in names in osgi.bundles of config.ini there's a difference:

Bundle - Filenames separating the version with underline „_“ can be used without the version:

easybeans-core

But if there's a minus „-“ you have to enter the full filename including versioning:

easybeans-core-1.1.0-SNAPSHOT

s.a. Bugzilla 240018.

Of course you can integrate the renaming into your build-process, but sometimes its handy to do it manually. Under OSX the application NameChanger helps. (Freeware)

Download EasyBeans Bundles, actual SNAPSHOT
unzip
open NameChanger
Drag'n'Drop EaysyBeans Bundles into NameChanger
Replace All Occurences of „-1.“ with „_1.“
Click on Rename

blog in german

PDE Target Platform - Avoid Duplicate Bundles [OSX]

2008-09-11T12:07:00.015+02:00

An important part while developing OSGI - Enterprise - Applications is the correct use of PDE Target Platforms. My current ERP project uses:

Eclipse SDK
Eclipse Equinox SDK
Eclipse Riena
....

While creating your Target Platform you'll notice that some downloads contain the same bundles, per ex. downloading Eclipse Platform SDK and Equinox SDK.

You should know that there are some problems with Target Platforms using duplicates at different locations. Bugzilla 209915, 233096. So its a good idea to avoid duplicates.

If you have installed Apples XCode Tools for OSX, then you can use the application FileMerge:

Whats our goal ? We need all bundles from Equinox SDK not contained in Eclipse Platform SDK. We choose the following directory locations:

LEFT: plugins folder from Platform SDK

RIGHT: plugins folder from Equinox SDK

MERGE: target plugins folder to get only those Equinox Plug-Ins not already contained in Platform SDK.

Click COMPARE:

EXCLUDE: Identical + Changed Left

EDIT Menu: Select ALL

MERGE - USE RIGHT

Now we can add the merged folder as location to our Target Platform.

blog in german

PDE and 3rdParty Bundles in OSGI Enterprise apps

2008-09-10T09:41:00.033+02:00

If you're developing an OSGI based Enterprise Application you'll always reach a point where you have to integrate external libraries, bundles or whole projects. In many cases PDE tooling will be your friend.

You have to watch some rules to make life easier - for you and others using your bundles. I already talked about this in previous blog entries. Hopefully it will help you to avoid chaos in your OSGI environment.

1. JAR - Files as Bundles

As a good citizen of OSGI world there's the first rule:

Rule 1:

Always put dependent JAR Files in separate bundles and describe the dependencies in your Manifest file.

Don't hide those JARs in your own bundle.

Then its much easier to re-use bundles or to let your bundles play together with others.

PDE makes it very easy to create bundles (plug-ins) from JAR - Files: Select New - Plug-In Development - Plug-in from existing JAR - archives, choose the JAR File - and thats it :-).

Attention - please use this comfortable function as last of your steps ! At first follow the next rule for good OSGI citizens:

Rule 2:

If a Bundle for your dependent JAR File already exists in one of the Bundle Repositories - then choose this.

Don't create your own bundles for existing ones.

How do you know, if there's already a bundle ? Here's my way to search bundles:

Does the bundle exist in the SpringSource Enterprise Bundle Repository ? SpringSource is my first choose, because all bundles and dependencies are described there in detail. A great thanks to the SpringSource Team for this great work.
Does the bundle exist in the Eclipse Orbit Repository ? You can find an overview here.
To be sure also search for the bundle at OSGI (look at OBR Bundle Repository).
Only if all search results are negative, I'm creating my own bundle with help of PDE as descibed above. If its a common JAR - File used in many projects, then I create an entry into SpringSource JIRA "wishing" to have this bundle there. Some time ago I was looking for bundles of Drools Rule Engine, but nothing exists in any of the repositories. So I put an entry into SpringSource JIRA. Some days later: „Mission completed“ - if you're now looking for it you'll find per ex.: Drools Rules Engine Core.

2. Using "foreign" Bundles

Great - with the help of the repositories of PDE - Tooling we got all the dependent bundles providing the needed functionality and APIs. Now we can integrate them into our own OSGI Project.

Analyzing other projects and bundles in many cases I found, that the easiest way was used: Need a bundle ? Put a dependency with Require-Bundle. And because its so fast and easy re-export it simply hitting „Re-Export this dependency“ in Manifest editor.

To get a clean OSGI architecture there's something more to think about ;-)

My next rule to watch follows. I know that there's some controverse discussion about required bundles vs. importing packages. But from my experiencies you should do this:

Rule 3:

If possible use Import-Package to resolve your dependencies.

Export only your "public" packages - no internal.

Use Require-Bundle only to resolve dependencies inside your own „universe“, not against common bundles.

Always version Require-Bundle, Import-Package und Export-Package.

Require-Bundle always has a dependency to a bundle with a specific name. You cannot change an Eclipse Orbit Bundle (per ex. org.apache.commons.logging) with a SpringSource Bundle (com.springsource.org.apache.commons.logging) if you're using Require-Bundle - only using Import-Package.

Import-Package isn't dependent from the name of the bundle, so its more flexible. Of course its more work to look at your packages and decide which you need to import or to export compared to a one-liner with Require-Bundle.

One example: Eclipse Riena needs a special Hessian Bundle because of Eclipse Buddy Policy. If you have a bundle where Require-Bundle points to another Hessian bundle you cannot use the one Riena needs. If you're using Import-Package you can avoid much trouble.

I have some more rules I'm watching to work easier with PDE:

Rule 4:

If a bundle itself contains packages inside the bundle and exports them, never put these packages also into the Manifest as imported packages.

This can cause PDE to detect cycles and then some functionalities of PDE tooling don't run as expected.

s.a. Bugzilla 246615, 246617 and 208011.

Rule 5:

Before deploying of a bundle as plug-in be sure the Package-Uses are re-calculated.

Wrong Package-Use entries for exported packages can stop PDE to export your Plug-In.

s.a. Bugzilla 246615.

Rule 6:

Avoid nesting JAR - Files - better use multiple bundles.

s.a. Bugzilla 157375 - esp. comment #31.

Workaround: If a dependency to a „foreign“ binary bundle with nested JAR Files is causing PDE Build - problems, most time it helps to load another plug-in exporting these classes into the workspace.

Attention: You need this plug-in only to build / compile your bundle not for Runtime or OSGI Launch Configurations, because Equinox has no problem using bundles with nested JAR Files.

If you watch these DOs & DON‘Ts, then I'm sure you have less trouble and chaos and also your bundles itself can easy be integrated into foreign OSGI projects.

3.Integration of whole ("foreign") OSGI Projekts

Sorry, but the reality isn't so easy as described above building complex OSGI Enterprise applications. You have to live with other projects not following those rules.

As an example try to integrate the OSGI EJB3 container from EasyBeans. EasyBeans contains some different components, utilities, an agent and a core bundle.

Not watching Rule 1 and Rule 2:

bundle org.ow2.easybeans.core contains uncount JAR Files (the core bundle has a size of 12 MB). Many of these JAR Files are already available as bundles in OSGI Repositories. This makes it very hard to work with the core bundle and to let your own architecture clean. The EasyBeans team knows about this, so hopefully in the future this will become better.

Not watching Rule 4 and Rule 5:

org.ow2.easybeans.core causes problems with PDE Dependency Analyzing: PDE reports cycles and wrong package-uses. If only using the easybeans.core bundle in runtime or OSGI launch configurations, all works perfect.

Problems arrive if an own bundle has dependencies to org.ow2.easybeans.core: PDE cannot export the bundle as Deployable Plug-In, because cycles and wrong Package - Uses are reported. (s.a. Bugzilla 246615)

Workaround to export your bundle with PDE tooling:

At first load bundle org.ow2.easybeans.core as Source Project into your workspace.

PDE reports incorrect Package-Uses of org.ow2.easybeans.core if you try to export your bundle as deployable plug-in. Open MANIFEST.MF of org.ow2.easybeans.core bundle from workspace, tab Runtime - Exported Packages re-caclulate Uses. Save MANIFEST.MF and try again to export your bundle.
Now PDE detects the cycles. Again open MANIFEST.MF, tab Dependencies, Dependency Analysis „Find unused Dependencies“ and remove all selected. Save MANIFEST.MF and try to export again.

Now you can export your bundle :-)

Remark: PDE is happy with this manipulated easybeans.core bundle - but never try to use this in runtime or from OSGI launch configs !

Problems with bundle - filenames:

EasyBeans uses filenames like

easybeans-component-hsqldb-1.1.0-SNAPSHOT

Eclipse uses filenames like

easybeans-component-hsqldb_1.1.0-SNAPSHOT

Did you notice the difference ? Eclipse uses underlines (_) before the version (1.1.0) and EasyBeans uses minus (-).

I'm always replacing -1.1.0 by _1.1.0 after downloading from EasyBeans. This makes some things easier, per ex. in bundle.info of config.ini I can use the plug-in - name only. Without replacing I always have to enter the whole filename, which means I have to change the config.ini for all version-changes, because Equinox cannot find the version number with all these "-" (Bug JIRA).

Problems with Bundle - Symbolic Names:

PDE has a problem using "-" in Symbolic Names. (s.a. Blog A dash of legacy from Chris Aniszczyk).

EasyBeans contains some Util Bundles, where the symbolic name contains "-" (per ex. org.ow2.bundles.ow2-util-event-api). If you load such bundles into your workspace, they are marked as error (Bundle symbolic name contains illegal characters. Legal characters are A-Z a-z 0-9 . _). You have to change the symbolic name.

Result:

Hopefully my rules, solutions and workarounds will help others fighting with OSGI bundle - dependencies.

If you're noticing problems with logging, please read my blog entries about "Logging in OSGI Projects".

Follow - Up:

Some more blogs are work-in-process and will follow soon to demonstrate the use of EasyBeans 1.1.0, Eclipse Riena M4 and Equinox 3.4 in a small example project.

blog in german

Equinox P2 - Thanks for "Revert Configuration"

2008-07-21T19:45:00.005+02:00

You know - there are some problems using P2, but today it was good using P2. After Updating to Mylyn 3.0.1 I couldn't open the Task List View:

(s.a. Bugzilla 241524)

But this is no problem - with P2 you're in luck: you can always revert to previous configurations:

Help | Software Updates | Installed Software | Revert Configuration

Find and select the configuration using Mylyn 3.0.0, hit Finish, restart Eclipse and you're done. Thats all you have to do !

... all runs as before :-)

Some asked why P2 doesn't remove unused bundles - think its clear now: P2 needs them to be able to revert to older configurations. Did you remember the old days before P2 how much time is costs to fix an update disaster ?

Thanks P2 :-) ...I saved much time.

ekke
in german

Logging (Riena - EasyBeans - Equinox) Reloaded

2008-07-18T09:17:00.004+02:00

There are some improvements since blogging about

Catch-22 Logging with OSGI Frameworks:

Eclipse Riena:
Eclipse Riena (M3 here for OSX and here for Windows) has changed the dependency to log4J from Require-Bundle into Import-Package - now you can use any log4j bundle, per ex. log4J from SpringSource Enterprise Bundle Repository (S2).

EasyBeans:
EasyBeans Version 1.1.0 (Snapshot here) can now work with installations using Commons Logging and also log4J - the stacktrace „ No suitable Log implementation“ doesn't happen anymore.

Now you can use configurations like:

Riena + log4J + S2-commons-logging + EasyBeans + ow2-commons-logging
If you want to use ow2-commons-logging bundle from EasyBeans distribution, then you need also S2-commons-logging, because Jetty (Riena dependency) needs an import with version number, but ow2-commons-logging exports the packages without a version.

Riena + EasyBeans + log4J + S2-commons-logging
Now you can completely remove ow2-commons-logging and only use commons-logging bundle from SpringSource - this bundle works together with EasyBeans 1.1.0 and also Jetty. (I also prefer not to use ow2-commons-logging in this case, because there's a dynamic-import of log4j and its always good to try to use as less dynamic-imports as possible.)

Remarks:
Riena still uses a special log bundle (equinox.log_1.1.0.HEAD) - details see here.
Instead of commons-logging from S2 (SpringSource) you can also use the commons-logging bundle delivered by Eclipse.

Thanks to the teams of Riena and EasyBeans for soon fixing of bugs making the life of an Enterprise OSGI applications developers easier.

the blog in german

Eclipse Ganymede P2 Installer trouble

2008-07-02T16:44:00.003+02:00

Today I tried again my workflow to install some shared installations and prepare a new blog about it.

Suddenly P2 Installer doesn't run any more. (you should read my blog Eclipse Ganymede - P2 Shared Installations (Bundle Pool) to understand the whole story ;-)

I deleted /configurations/.settings and /p2 from P2 Installer directory and started P2 Installer again. This time I got a message and was pointed to the .log file to be found in /configurations and there was really an error logged:

java.lang.OutOfMemoryError: Java heap space...

So I modified the p2installer.ini and added:

-Xms256m
-Xmx1000m
-XX:MaxPermSize=256m

Then I started again the P2 Installer

This time the installer downloads all plugins into my bundle pool location and then runs and runs and runs and runs ...

After some time I looked at the OSX activity monitor and noticed:

SWT (= P2 Installer Application) consumes 1 GB physical RAM and runs endless until I killed the task. Then I deleted the content of my bundle pool directory, the /configuration/.settings and /p2 from P2 Installer Directory.

...and started again:

Now it runs perfectly AND the P2 Installer asks at the end if I want to start the SDK :-)

Memory consumed was now only up t0 100 - 200 MB

Of course I did the next test and started P2 Installer again for the second (shared) installation and it also runs without any problems - memory consumed this time only 60 - 170 MB

You remember from my last blog Eclipse Ganymede - P2 Shared Installations (Bundle Pool) that always the first run of P2 Installer for shared installations quits without any message, the second run works well. From my experiences today it seems that it was a memory problem, but nothing was logged by P2 Installer. The installed Eclipse SDK runs without an error - but who knows if all was really correctly installed ?

I used TimeMachine to look back to .log files from previous installations, but never found a error msg that there isn't enough memory.

I added these informations to bugzilla 238947.

conclusion:

add -Xms, -Xmx, -XX to the P2 installer (think the defaults from normal eclipse.app will be ok - not everyone can use 1000m like me ;-)
if P2 Installer hangs: delete /configura/.settings and /p2 before restarting
if P2 Installer disappears without any message: look into .log if there's something reported, dont rely on the installation, extend memory allocation, delete installed SDK and start again

ekke

hello planet eclipse

2008-07-02T16:28:00.007+02:00

... perhaps someone has noticed that on monday the first time a blog from me appears at Planet Eclipse: "Eclipse Ganymede - P2 Shared Installations (Bundle Pool)"

I'm glad that I'm now listed at Planet Eclipse where I myself have learned so much from the experience of you all and I hope some of you will enjoy what I'm writing on...

I'm working as an independent software architect / business application developer since 30 years now and I'm using Eclipse since Version 2.

My actual project is a german ERP solution for small and medium sized companies of Waste & Recycling. The core of the application and also the developed openArchitectureWare cartridges will become open source (EPL).

The ERP solution is

model-driven (Eclipse Modeling Project, openArchitectureWare)
OSGI Client/Server Architecture (Equinox, Eclipse Riena, EasyBeans OSGI)
Business Process / Business Rules Driven (jBPM, Drools)
RCP Client (SWT/JFace, Eclipse Databinding, Instatiations SWT Designer)
...

I'll report here about all what happens around the development of such a complex business application.

At the moment I'm fighting with P2 ;-)
...but I'm still thinking its worth to try

ekke
my blogs are also available in german

Eclipse Ganymede - P2 Shared Installations (Bundle Pool)

2008-06-29T21:58:00.022+02:00

Eclipse Ganymede and P2 will change your update workflows from ground up.

There are some Cons (I'm missing the external locations from Software Update),

but many Pros so for me its time to change.

If you don't want you can still use the old Update Manager. (Preferences - General - Capabilities)

There are many new things in P2 - today I'll concentrate on:

Dropins - a folder where you can place and structure plugins. These plugins were scanned at startup automagically by Eclipse P2.
Bundle Pooling - now its possible that some Eclipse Installations can share their bundles using the Bundle Pool.

In my project I'm using some Eclipse Instances:

Eclipse for Modeling (EMF, UML2, openArchitectureWare, ...)
Eclipse for OSGI Client/Server (Eclipse Riena, RCP, Equinox, EasyBeans, ...)
....

The old classic way I had to download the Ganymede Packages for Modeling and also the Ganymede Packages for RCP/Plugin and then manage them separately.

Eclipse P2 allows bundle pooling and now we'll try to install this.

Attention: All installation examples in this blog are OSX specific - perhaps you have to make some fine tuning for your OS.

Shared Installations - first try

As good Eclipse „citizens“ at first we look at the Eclipse wiki and read from Equinox P2 Getting Started and Equinox P2 Installer and then we're ready to start:

Download the P2 Installers from here - we choose the Mac OSX version:
equinox.p2.installer-3.4-macosx.carbon.ppc.tar

Doubleclick to unzip the Installer into /your_path/e34p2installer and open the installer /your_path/e34p2installer/eclipse/p2installer.app:

We're choosing Shared install, select our Product install directory (/your_path/e34modeling) and start the p2 Installer.

It takes some time to download the SDK bundles - unfortunately I cannot select a prefered mirror and there's also no chance to select the Friends of Eclipse Mirror ;-)
see @ Bugzilla 215916

Suddenly the window of the P2 Installer disappears without any message - but lets think positive and start the new Eclipse from /your_path/e34modeling.

All runs well without any problem or error :-)

But its not the end of the story - otherwise there would be no reason to write this blog ;-)

Where are the shared plugins stored ? Where's my bundle pool ? You remember: there was no possibility to select the bundle pool location from p2 Installer.

Searching the Getting started under Bundle pooling we found an example:

Documents and Settings
Username
.p2/
org/eclipse.equinox.p2.core
org/eclipse.equinox.p2.director
org/eclipse.equinox.p2.engine
org/eclipse.equinox.p2.touchpoint.eclipse
plugins/ <-- shared bundle pool But there are no plugins - the plugins of the bundle pool were stored into the P2 Installer location: /your_path/e34p2installer/eclipse/p2/ org.eclipse.equinox.p2.touchpoint.eclipse/plugins/

Now you're in luck if you don't followed the advice to delete the P2 Installer („... When finished, you can delete the installer...“) ;.-)

We need a way to select the location of your bundle pool - lets start a next try:

Shared Installations - second try

Download and unzip the P2 Installer as described above and look into the p2installer.ini file (you'll find this file under /your_plugin/e34p2installer/eclipse/p2installer.app/Contents/MacOS/ p2installer.ini ).

Inside the p2installer.ini you'll find a link to a properties file. Please open http://download.eclipse.org/eclipse/testUpdates/sdk-installer.properties in your webbrowser and you'll see:

eclipse.p2.metadata=http://download.eclipse.org/eclipse/updates/3.4milestones/
eclipse.p2.artifacts=http://download.eclipse.org/eclipse/updates/3.4milestones/
eclipse.p2.flavor=tooling
eclipse.p2.profileName=Eclipse SDK
eclipse.p2.launcherName=eclipse
eclipse.p2.rootId=org.eclipse.sdk.ide
eclipse.p2.autoStart=true

Copy the content from the browser window into an empty textfile and add following entry pointing to the bundle pool:
eclipse.p2.bundleLocation=/your_path/e34pool

Save this textfile under /your_path/e34p2installer/sdk-installer.properties

Now we have to open the p2.installer.ini file to change the path of the sdk-installer.properties:

-Dorg.eclipse.equinox.p2.installDescription=
file:/your_path/e34p2installer/sdk-installer.propertiesfile: /your_path/e34p2installer/

Start the P2 Installer, select the product install directory (/your_path/e34modeling - screenshot see above from first try)

The same happens again: the P2 Installer appliation disappears without any message - but Eclipse (from /your_path/e34modeling) runs without problems and now all shared plugins are stored in our bundle pool under /your_path/e34pool/plugins :-)
2008-07_02 add-on: its not ok, that the P2 installer disappears - you have to add more memory, delete all and start again. see additional info in blog P2 Installer Trouble

Now we want to install the second Eclipse installation (/your_path/e34osgi_rcp) and so we start again the P2 Installer, select our product install directory, choose Shared Installation and really - this time it takes only some seconds to "download" and install the Eclipse SDK :-)

Really great P2 !

But whats that:
This time the P2 Installer window remains open and asks if we want to start Eclipse SDK immediately.

After some tests it was reproducable: in shared installations the first time a bundle pool was used the p2 installer disappears without any message.

Both SDK installations run without any problems - About Eclipse - configuration details logs that all bundles come from our bundle pool.

Good work, P2 :-)

Configure Eclipse Installations

The first steps were easy - but now you have to do some work: - unfortunately there are no prepared shared Installs like Ganymede Packages (I have found none)

Instead of selecting a whole package or groups of plugins we have to choose and select them plugin for plugin: Please start your two SDK installations and select menu Help - Software Updates...

Installed Software shows the already installed Eclipse SDK.

Got to tab Available Software - Ganymede Update: there you'll find the needed plugins. P2 makes sure, that all dependencies will satisfied, only correct combinations will be installed - so we always have a correct installation running.

In my ERP project one Eclipse installation (/your_path/e34modeling) contains the plugins from Ganymede Modeling Package + ECF and the other Eclipse installation (/your_path/e34osgi_rcp ) contains the plugins from Ganymede RCP/Plugin Package + Ganymede Reporting + Subversion.

To get an idea whats needed you can take a look at the feature lists of the Ganymede Packages, per ex. for the modeling package:

After configuring both Eclipse Installations we can look at our bundle pool to see that all plugins are contained in the one and only bundle pool :-)

Would be really nice using Software Update to select bundles directly from your bundle pool. This would be an easy way to get bundles not contained in the actual Eclipse Installation, but already installed in another Eclipse application sharing the bundle pool.
So you have to select all bundles thru the updatesite - even if they are already contained in the bundle pool.

Dropins and Bundle Pool

After finishing the installations using Software Update... in many cases you have to install more (external) plugins (bundles).

You can use two different strategies:

Bundles from Update Sites (Menu Software Updates... - Available Software... Add Site...) - this works the same as in previous Eclipse versions, but without the possibility to store them at external locations
Bundles using the new Dropins folder (a „Watched Directory“). At startup Eclipse will scan this dropins folder automatically to see if there are new or changed plugins. All bundles from the dropins folder are added to the current Eclipse Installation.

This dropins folder will be found directly inside your Eclipse Installation directory parallel to the Eclipse Application.

You can also use an own extra dropins folder: simply add a parameter into eclipse.ini (/your_path/Eclipse.app/Contents/MacOS):

-Dorg.eclipse.equinox.p2.reconciler.dropins.directory= /your_path/e34shared_dropin

This extra dropins location can be used from more then one Eclipse installations - so you can use it as a shared dropins (watched directory).

Now we have all pieces together:

Each Eclipse Installation only uses those bundles from bundle pool, which were selected from Software Update..., also the bundles from the (default) own dropins folder and perhaps bundles scanned from an extra (shared) dropins location.

You can put bundles into a dropins folder in different ways as decribed into the Getting Started.

Using link files inside your dropins directory you can manage external locations, but you loose the possibility to install them from inside Eclipse using Software Update...

Shared Installations and Target Platforms

I found out some problems with shared installations and the use of target platforms (Preferences - PDE - Target Platform).

If you create a target platform only from external locations then there's no difference to previous versions of Eclipse because you select the bundles to use by yourself without using bundles from your current Eclipse application.

But if you dont want to configure the target platform completely and instead use your current Eclipse as target, then there are some bugs:

Using Eclipse as shared installation you cannot select the bundles configured for your current Eclipse application as target platform
Bundles from dropins locations are not recognized in shared installations

Using Shared Installations the default target platform points to the bundle pool listing ALL bundles from your bundle pool, so you see also bundles from other Eclipse installations in you default target and you have to deselect the not-used bundles:

I think there should be also an option to automatically „Disable bundles not used in current Eclipse Installation“.

Next problem with dropins in shared installations. Getting Started... notes „In other words, new plug-ins installed via the dropins folder behave exactly like plug-ins installed via the user interface.“

Attention: If you're using a shared installation the bundles from your dropins are missing !
You only see all bundles from pool (and there you are seeing too much as described above) and you dont see the bundles from your dropins.

The only way to change this is using Add.. for all plugins folders inside your dropins. If you have structured your dropins, this means you have to select each plugins folder from there. It can happen easily to forget something or loosing the overview.

Shared Installations brings you much more comfort, but also more work with target platforms :-(

If you're using separate (not shared) installations then the behaviour is as aspected - the bundles from all your dropins plugins folders appear automagically in your target platform:

I hope, that these bugs will be fixed soon:

Bugzilla 236923 [installer] p2 shared installation does not works without the installer directory
Bugzilla 238947 P2 Installer Window disappears
Bugzilla 238949 P2 Shared Installations - Target Platform too much bundles
Bugzilla 238950 P2 Shared Installations - Target Platform Dropins missing

and some enhancements as well:

Bugzilla 238952 Feature Request P2 Software Update should be able to select from Bundle Pool
Bugzilla 238953 request P2 Installer select Bundle Pool Location

as always: if you're interested, then please Vote for the Bugzillas ;-)

Conclusion

Over all P2 is a great step into te right direction - and please remember: its the first release - so give it a try !

the blog in german

Eclipse Ganymede - IDE and platform

2008-06-16T18:21:00.007+02:00

2008 - june - 25

I started using Eclipse with version 2 as Java IDE.

Now (25th of june 2008) version 3.4 (Ganymede) will be ready to download.

Eclipse evolves over the years and now acts as a platform.

There are so many projects hosted at Eclipse.org - who knows all their names...

The Ganymede release counts 24 projects ready to download.

In my ERP project I'm using

Eclipse as IDE
Eclipse RCP - Rich Clients under windows and OSX
BIRT - Reporting
Eclipse Riena - Remote (Client/Server)
Equinox - OSGI Plattform
Eclipse Modeling - openArchitectureWare
SWT / JFace / Eclipse Databinding - GUI
Mylyn - Taskmanagement
.....

Remark: Eclipse Riena is a new project and not part of Ganymede

Here are some of the news worth switching to Ganymede.

It's only a small part of all the new things making your daily work easier then before - wether you're using Eclipse as IDE, for Plugin - Development, with Mylyn, Birt or other projects ...

More comfort developing plugins (PDE)

Plugin Spy

tells you all you want to know from dialogs or windows.

Remark:
on my Mac under OSX I couldn't use the keystroke alt-Shift-F1 - after changing to alt-Shift-F13 it works.

Launch Configurations now can be exported to the local filesystem and also imported from there.

Remark:

I'm using variables in my launch configurations - so they are portable and I can easy change them between different projects exporting / importing to local files.

PDE Tools --> Convert Jars to Plugin-Projects...

In PDE now its possible to create a plugin - project from a single jar. This makes it easy to design a clear plugin structure without storing external jars inside of your bundles.

Attention: You should only create your own bundle if there doesn't exist one for this jar. Please search at first at OSGI or at SpringSource Enterprise Bundle Repository.

Java Editor

Breadcrumbs: the Java editor optionally shows a breadcrumb bar.

From this bar you can easy navigate through the path of your java file and tree structures to open other java files in the editor - a very fast and comfortable way to access other classes, interfaces, methods,... from your current context.

JavaDoc Hover
You know the situation: pointing with your mouse cursor over a declaration a hover shows you JavaDoc informations.

Wouldn't it be great to jump directly into the hover, scroll the text etc. ?

With Ganymede you can do it now !
Point your mouse a second inside the hover and you can jump in and scroll or even execute some actions from there. (Please watch the toolbar at the bottom)

For me this is one of the coolest things in Ganymede.

Better support for OSX

JREs: All installed JRE‘s will now be detected automagically.

Voice Over (Command-F5) is now supported from Eclipse. Maybe I'll need this later.

Drag‘n‘Drop support in trees now shows the insertionpoint more exactly then before under OSX.

Mac Cocoa Port of SWT is still under construction and not ready to use with Ganymede :-(
But there must be a reason to wait for first milestones of Eclipse 3.5 ;-)

this bog in german

Catch-22 Logging with OSGI Frameworks

2008-06-16T00:59:00.007+02:00

Logging is easy and there are no problems since apache.log4j and apache.commons.logging etc. exist. Using OSGI bundles its also easy to have the correct versions of bundles in your classpath. Standard Bundles can be re-used easy in OSGI frameworks - the newest example in this direction is SpringSource Enterprise Bundle Repository. Hey - logging paradise is out there ....

My actual project (ERP solution) has to integrate Eclipse Riena, EasyBeans and Equinox. Some problems were to resolve to make Riena and EasyBeans run under Eclipse + Equinox 3.4.RC4. (see also here and here)

The focus of this blog is only logging if these projects were used together - I'll talk later about the functional use.

The first small problem was easy to solve: Eclipse Riena needs a special version of equinox.log - replacing the equinox.log bundle from Equinox SDK with the version from Riena also works with EasyBeans.

Riena Logging

Riena has a dependency to log4j (Require-Bundle) - would be better to use Import-Package instead to make it possible to use log4j Bundles from other repositories.

Riena uses Jetty (contained in Equinox SDK and Platform SDK), Jetty itself has a dependency to org.apache.commons.logging (Import-Package).

All works well with Eclipse Riena - org.apache.commons.logging detects org.apache.log4J and uses this implementation.

EasyBeans Logging

EasyBeans components are also dependent from von commons.logging (Import-Package) and they found this package as part of the EasyBeans Bundle ow2-bundles-externals-commons-logging.

As expected - this works wel with EasyBeans - commons.logging sees no log4j and uses the Java JDK Logging.

Riena and EasyBeans Logging - the problems

Are we happy with logging ? YES ! ...if we only use Riena OR EasyBeans - but not together :-(

Unfortunately the logging in EasyBeans has an implementation only working with JDK - Logging.

But org.apache.commons.logging chooses log4j - if found - and doesn't look for the JDK logging as implementation.

Running Riena and EasyBeans without changes together (changing start-level doesn't matter), then there's an error from commons.logging @ EasyBeans Bundle: NoClassDefFoundError: org/apache/log4j/Category

Next try: We remove the Equinox Bundle org.apache.commons.logging. EasyBeans Bundle ow2-bundles-externals-commons-logging also exports the contained org.apache.commons.logging - packages.

Starting again bundle org.mortbay.jetty reports an error: org.apache.commons.logging expected from version 1.0.0 - the EasyBeans Bundle instead exports org.apache.commons.logging without any version.

Another try: We replace org.apache.commons.logging with com.springsource.org.apache.commons.logging from SpringSource Enterprise Bundle Repository and restart. Now com.springsource.org.apache.commons.logging reports an error: import of log4J needs version 1.2.15, org.apache.log4J from Riena is version 1.2.8 and doesn't match. We can't use com.springsource.org.apache.log4j from Spring, because Riena uses Bundle-Required instead of Import-Package.

Also EasyBeans reports an error: No suitable Log implementation

EasyBeans cannot use log4j as logger - only JDK logging.

Riena and EasyBeans Logging - the solution

use equinox.log_1.1.0.HEAD from Riena instead of equinox.log_1.1.0 from Equinox SDK
remove org.apache.commons.logging from Equinox SDK
patch org.mortbay.jetty from Equinox SDK / Platfprm SDK: remove version from Package-Import org.apache.commons.logging

It's not an elegant solution, but it works: I'm able to log from Riena and EasyBeans running together in Equinox !

My wishes

Riena should use Package-Import instead of Bundle-Required for org.apache.log4j (Bugzilla 237221 and Newsgroup)
Riena should use standard equinox.log_version instead of equinox.log_version.HEAD, perhaps adding a fragment for additional functionality from equinox.log. (Newsgroup)
EasyBeans should also work using „standard“ org.apache.commons.logging bundles (from Equinox, Spring etc). EasyBeans should also allow log4j as logging implementation (JIRA)

This would make life as an OSGI - application developer easier. Please vote for the bugs - thanks !

blog in german

Eclipse Riena Getting Started in Ganymede (Eclipse 3.4)

2008-06-12T22:36:00.014+02:00

Only two weeks remaining and the next Eclipse Version 3.4 (Ganymede) can be downloaded. This time there are 24 projects together with simultan releases.

It makes sense to start working with Ganymede - but even 24 projects are only a small part of the big Eclipse universe.

So - what do I need in my project, what's not part of Ganymede:

openArchitectureWare 4.3 runs successfully under Ganymede.

EasyBeans - a "foreign" project - I already found the soution how to make it run under 3.4.

Eclipse Riena 1.0.M2 is only available (at the moment) for Eclipse 3.3.

This blog will show you how to make Eclipse Riena run under Ganymede.

The download from Riena provides a target platform containing bundles from Eclipse SDK 3.3, Equinox 3.3 and Riena 10.M2 - also some "external" (Hessian, Log4J, ...).

Please read my blog "PDE Target Platform from different locations (Bugs)" before you go on.Because of these problems we have to build the target platform „manually“ from:

Eclipse Platform SDK 3.4 (we're using the SDK as IDE and also as Host for the target platform)f
rom Equinox SDK 3.4 some bundles which are not contained in the Platform SDK
from Riena M2 - download all *.riena.* Bundles, Hessian and Log4J

Remarks:

Log4J can be used from Riena distribution or from SpringSource Enterprise Bundle Repository.
Problem with org.junit bundle from Platform SDK: If you followed the documentation "Riena Getting started" from Riena wiki and imported the bundle org.eclipse.riena.tests as Plug-in with Source into your workspace then you'll notice some errors, because Ganymede uses org.junit4. Please replace org.junit in project org.eclipse.riena.tests, MANIFEST.MF, Dependencies --> Required Plug-ins with org.junit4 from Eclipse Platform SDK 3.4.

If you create the following folder - structure for your target platform, then you can use my prepared Target Definition Files (see below) and easyly create your target platform.

${target_riena}/
---- fromEquinoxSDK/
-------- eclipse/
------------plugins/
---- fromRienaM2/
-------- eclipse/
------------plugins/

Here you can see the content of the plugins - folders:

Remark:

bundle org.eclipse.equinox.log.1.1.0 from Equinox 3.4 can't be used, because Riena uses a modified version org.eclipse.equinox.log.1.1.0.HEAD containing a class org.eclipse.equinox.log.Logger. Please use the HEAD version from Riena M2 and delete the bundle from Equinox 3.4 inside the folder of the target platform.

Target Definition File (2 different versions)

You can create new Target Definition files using menu File --> New --> Target Definition.

To make it comfortable I've prepared files you can download, unzip and vopy into your workspace:

riena.target.zip und riena_minimal.target.zip.

riena_minimal contains only the smallest set of needed bundles to start a Riena server and to run the Riena Unit tests. Please dont forget to read the documentation Riena getting started from Riena wiki.

Please create a new variable target_riena under Preferences --> Run/Debug --> String Substitutions pointing to the root of the target platform folder.

After opening the file riena.target in your workspace you should see:

riena_minimal contains only 64 bundles instead of 126 bundles.

If you click on Set as Target Platform you can start using this target platform and easy change to another target.

Now have fun to start working with Riena 1.0.M2 under Ganymede.

One of my next blogs will show the use of Eclipse Riena together with EasyBeans in Ganymede.

this blog in german

PDE Target Platform from different locations (Bugs)

2008-06-09T15:44:00.010+02:00

I'm using Eclipse Riena for my ERP project. Riena's version is actually 1.0.M2 for Eclipse 3.3.

Riena provides an already configured target platform as download - featuring bundles from Eclipse SDK, Equinox and Riena, also some 'foreign' bundles like Hessian, Log4J, ... - but all these bundles are from Eclipse Platform SDK / Equinox 3.3.

So I had to manage the task to build a new target platform designed to run with Eclipse 3.4 (actually version 3.4.RC3).

We need:

Eclipse Platform SDK 3.4 (as IDE and target platform)
Equinox SDK 3.4 (target platform)
Riena - Bundles (target platform)
other Bundles from Riena - distribution (target platform)

Target Definition File (Bug using different locations and versions)

From my opinion the easiest (and comfortable) way in such situations is to create a Target Definition File: Menu File --> New --> Target Definition:

As usual I'm working with variables, so the definitions are easy to port into other workspaces and Eclipse versions.

Under Overview I choose / add three locations: Riena, Equinox und SDK.

Under Content I can select which of the plug-ins I want to use in my target platform.

Unfortunately it doesn't work as expected :-(

If you try to add the plug-ins you're seeing only plug-ins from one location - there's no way to decide which plug-ins should be selected from which locations.

Bug 233095 ([target] deal with multiple versions of bundles and different locations)

Target Platform Preferences (Bug using different locations and versions)

The next try: to build the target platform directly using Preferences --> Plug-in Development --> Target Platform:

Using Add... different locations can be selected. If Group plug-ins by location is marked you can see all plug-ins from these locations.

Then its possible to select the bundles you need from each of the 3 locations (Riena, SDK, Equinox). The example above shows 110 of 467 bundles selected.

Doesn't this look nice ? Yes - and after hitting Apply you can start your Riena - Server, run Tests etc.

Now the best you can do is to never restart Eclipse ;-) ... after restarting eclipse you'll see:

Now there are only 53 instead of 110 plug-ins (bundles) selected for your target platform - and the selected ones are other ones then before.

Bug 233096 Preferences - PDE - target platform - after restart selection changed

So because of these two bugs its not possible to build target platforms from some locations if there are multiple versions of plug-ins.

BTW: Please vote for bugs 233095 and 233096, if you also need to be fixed. thx.

this blog in german:

EasyBeans und Equinox

2008-06-05T16:17:00.029+02:00

After the decision to design my upcoming ERP solution as OSGI - Client/Server application using Eclipse Riena (Remoting, ObjectTransactions), Equinox (OSGI) and Hibernate (JPA / ORM) one point remains open: how to integrate EJB (Stateless and Stateful Sessionbeans) ?

The answer: there's a great open source EJB - OSGI solution: EasyBeans.

First step:

Integrate EasyBeans with Eclipse 3.4 + Equinox 3.4. (EasyBeans default OSGI framework is Felix from Apache)

... here's my HowTo:

What do we need: Eclipse Platform SDK, Equinox SDK and Easybeans OSGI - Hibernate-Version. All tests are done and are only running under Eclipse 3.4. At the moment of writing this blog Eclipse 3.4.RC3 is the newest one and EasyBeans OSGI 1.0.0:

Eclipse Platform SDK download
Equinox SDK download
EasyBeans OSGI Hibernate download

We have to differentiate between Eclipse as IDE and as target platform. At first you should install Eclipse Platform SDK as IDE as usual.

If you want to follow this tutorial then you should create a folder structure for the target platform as below.

To make the configuration and installation portable, we define a variable in Eclipse pointing to the root of our target files: ${target_easybeans}.

Then we create the following structure at

${target_easybeans}/

No we have to copy the needed plug-ins (bundles).

Which plug-ins you should copy depends on the needs of your project - to be flexible I made examples for two different target platforms: easybeans_target_full and easybeans_target_minimal.

You can download the two target definition files to import them into your Eclipse project: easybeans_target_full.target.zip and easybeans_target_minimal.target.zip.

easybeans_target_full (complete environment)

please copy into ${target_easybeans}/easybeans_target_full/eclipse/configuration/plugins:

all from Eclipse Platform SDK plugins - folder
all from Equinox SDK plugins - Ordner, if not contained in Platform SDK - Plugins)
from ow2-easybeans-osgi-1.0.0/bundles: all without *.felix.*

easybeans_target_minimal (Target Platform only with needed bundles)

please copy into ${target_easybeans}/easybeans_target_minimal/eclipse/configuration/plugins:

from Equinox SDK:

org.eclipse.osgi
org.eclipse.equinox.common
org.eclipse.osgi.services
org.eclipse.equinox.cm
org.eclipse.equinox.ds
org.eclipse.equinox.log
org.eclipse.equinox.util

from EasyBeans bundles:

ow2-bundles-externals-commons-logging
easybeans-core
easybeans-component-carol
easybeans-component-hsqldb
easybeans-component-jdbcpool
easybeans-component-joram
easybeans-component-jotm
easybeans-component-quartz
easybeans-agent

if wanted also the examples - bundles from EasyBeans:

easybeans-example-osgi
easybeans-examples-entitybean
easybeans-examples-mdb
easybeans-examples-migrationejb21
easybeans-examples-security
easybeans-examples-statefulbean
easybeans-examples-statelessbean
easybeans-examples-timerservice

Warning

Bundles from EasyBeans (Version 1.0.0) were not named like Equinox - rules: easybeans-core-1.0.0 should be easybeans-core_1.0.0. You can simple rename the bundles (change minus inti underline) or to use the name together with the version if adding bundles to bundle.info from config.ini. (Bug JIRA)
Bundle easybeans-component-joram-1.0.0 contains a wrong import in MANIFEST.MF: com.scalagent.scheduler This import must be removed. (Bug JIRA)

Its always a good idea to define Target Definition files for your target platforms in Eclipse: Menu File-->New-->Target Definition

After defining the targets you can change to this target with one click from within the target definition file or you do it directly from Preferences - Plug-in Development - Target Platform:

Please check the box (yellow marked). Because we want to build the target platform only using the plug-ins (bundles) stored at target platform location. (see the blog from Chris Aniszczyk)

To start EasyBeans easy ;-) in Eclipse we create OSGI Launch configurations.
Run Configurations...
We need two different OSGI Launch configurations:

first launcher uses a configuration file (config.ini in folder configuration), where all bundles were listed under property bundle.info
second launcher runs without using a configuration file - all bundles and arguments are defined directly in the launch configuration

OSGI Framework Launch Configuration with config.ini

There are no bundles selected from target platform, because they are all listed inside config.ini.

The most important program argument is -configuration, you also see the use of the defined variable. Inside this configuration folder you have to place the config.ini.

Content of config.ini:

Its no application - we only want to run these bundles:

eclipse.ignoreApp=true
osgi.noShutdown=true

Following bundles have to be installed and partly to be started from OSGI framework:

osgi.bundles=\
org.eclipse.equinox.common@2:start, \
org.eclipse.osgi.services@start, \
org.eclipse.equinox.cm@start, \
org.eclipse.equinox.ds@start, \
org.eclipse.equinox.log@start, \
org.eclipse.equinox.util@start, \
ow2-bundles-externals-commons-logging-1.0.5@start, \
easybeans-core-1.0.0, \
easybeans-component-carol-1.0.0, \
easybeans-component-hsqldb-1.0.0, \
easybeans-component-jdbcpool-1.0.0, \
easybeans-component-joram-1.0.0, \
easybeans-component-jotm-1.0.0, \
easybeans-component-quartz-1.0.0, \
easybeans-agent-1.0.0@start, \
easybeans-example-osgi-1.0.0, \
easybeans-examples-entitybean-1.0.0, \
easybeans-examples-mdb-1.0.0, \
easybeans-examples-migrationejb21-1.0.0, \
easybeans-examples-security-1.0.0, \
easybeans-examples-statefulbean-1.0.0, \
easybeans-examples-statelessbean-1.0.0, \
easybeans-examples-timerservice-1.0.0

Informations about bootdelegation - these packages are loaded from system classloader:

org.osgi.framework.bootdelegation=sun.*,com.sun.*

System packages - these packages are exported from the OSGI system bundle and can be imported from other bundles:

org.osgi.framework.system.packages=org.osgi.framework; version=1.3.0, \
javax.accessibility; \
javax.activity; \
javax.imageio; \
javax.imageio.event; \
javax.imageio.metadata; \
javax.imageio.plugins.bmp; \
javax.imageio.plugins.jpeg; \
javax.imageio.spi; \
javax.imageio.stream; \
javax.management; \
javax.management.loading; \
javax.management.modelmbean; \
javax.management.monitor; \
javax.management.openmbean; \
javax.management.relation; \
javax.management.remote; \
javax.management.remote.rmi; \
javax.management.timer; \
javax.naming; \
javax.naming.directory; \
javax.naming.event; \
javax.naming.ldap; \
javax.naming.spi; \
javax.net; \
javax.net.ssl; \
javax.print; \
javax.print.attribute; \
javax.print.attribute.standard; \
javax.print.event; \
javax.rmi; \
javax.rmi.CORBA; \
javax.rmi.ssl; \
javax.security.auth; \
javax.security.auth.callback; \
javax.security.auth.kerberos; \
javax.security.auth.login; \
javax.security.auth.spi; \
javax.security.auth.x500; \
javax.security.sasl; \
javax.sound.midi; \
javax.sound.midi.spi; \
javax.sound.sampled; \
javax.sound.sampled.spi; \
javax.sql; \
javax.sql.rowset; \
javax.sql.rowset.serial; \
javax.sql.rowset.spi; \
javax.swing; \
javax.swing.border; \
javax.swing.colorchooser; \
javax.swing.event; \
javax.swing.filechooser; \
javax.swing.plaf; \
javax.swing.plaf.basic; \
javax.swing.plaf.metal; \
javax.swing.plaf.multi; \
javax.swing.plaf.synth; \
javax.swing.table; \
javax.swing.text; \
javax.swing.text.html; \
javax.swing.text.html.parser; \
javax.swing.text.rtf; \
javax.swing.tree; \
javax.swing.undo; \
javax.xml; \
javax.xml.datatype; \
javax.xml.namespace; \
javax.xml.parsers; \
javax.xml.transform; \
javax.xml.transform.dom; \
javax.xml.transform.sax; \
javax.xml.transform.stream; \
javax.xml.validation; \
javax.xml.xpath; \
org.ietf.jgss; \
org.omg.CORBA; \
org.omg.CORBA_2_3; \
org.omg.CORBA_2_3.portable; \
org.omg.CORBA.DynAnyPackage; \
org.omg.CORBA.ORBPackage; \
org.omg.CORBA.portable; \
org.omg.CORBA.TypeCodePackage; \
org.omg.CosNaming; \
org.omg.CosNaming.NamingContextExtPackage; \
org.omg.CosNaming.NamingContextPackage; \
org.omg.Dynamic; \
org.omg.DynamicAny; \
org.omg.DynamicAny.DynAnyFactoryPackage; \
org.omg.DynamicAny.DynAnyPackage; \
org.omg.IOP; \
org.omg.IOP.CodecFactoryPackage; \
org.omg.IOP.CodecPackage; \
org.omg.Messaging; \
org.omg.PortableInterceptor; \
org.omg.PortableInterceptor.ORBInitInfoPackage; \
org.omg.PortableServer; \
org.omg.PortableServer.CurrentPackage; \
org.omg.PortableServer.POAManagerPackage; \
org.omg.PortableServer.POAPackage; \
org.omg.PortableServer.portable; \
org.omg.PortableServer.ServantLocatorPackage; \
org.omg.SendingContext; \
org.omg.stub.java.rmi; \
org.omg.stub.javax.management.remote.rmi; \
org.w3c.dom; \
org.w3c.dom.bootstrap; \
org.w3c.dom.css; \
org.w3c.dom.events; \
org.w3c.dom.html; \
org.w3c.dom.ls; \
org.w3c.dom.ranges; \
org.w3c.dom.stylesheets; \
org.w3c.dom.traversal; \
org.w3c.dom.views; \
org.xml.sax; \
org.xml.sax.ext; \
org.xml.sax.helpers; \
sun.rmi.server; \
sun.rmi.transport; \
sun.rmi.registry; \
version=1.5.0

Even while testing its a good idea to use an own location for the Configuration Area in the settings of the launch configuration. (We also use our above defined variable here).

Here you can download the launch configuration: easybeans (bundle.info in config.file).launch.zip
And the config.ini for this scenario: config.ini.zip

OSGI Framework Launch Configuration without config.ini

In this case you have to select the needed bundles in the launcher.

Please watch the Start Level: equinox.common needs Level 2, all the other bundles get automatically the Default Start Level 4 and then the easybeans.agent with Start Level 5 will be started.

The other bundles from easybeans have set Auto-Start = false, because its the task of the easybeans.agent to start them in the right order.

At programm arguments there's no -configuration - of course all of them now have to be defined as VM Arguments.

Please watch, that -Dorg.osgi.framework.system.packages has to be entered without any spaces - the other arguments are identical to the content of the config.ini in the first scenario.

And here's the launch configuration to Download: easybeans (launch config).launch.zip

YOU ARE READY - all configuration and installation is done and you can run EasyBeans with different target platforms and different OSGI Framework launch configurations.

Framework is launched.

idState Bundle
0ACTIVE org.eclipse.osgi_3.4.0.v20080521-1400
1ACTIVE org.eclipse.equinox.common_3.4.0.v20080421-2006
2ACTIVE org.eclipse.osgi.services_3.1.200.v20071203
3ACTIVE org.eclipse.equinox.cm_1.0.0.v20080509-1800
4ACTIVE org.eclipse.equinox.ds_1.0.0.v20080427-0830
5ACTIVE org.eclipse.equinox.log_1.1.0.v20080414
6ACTIVE org.eclipse.equinox.util_1.0.0.v20080414
7ACTIVE org.ow2.bundles.ow2-bundles-externals-commons-logging_1.0.5
8ACTIVE org.ow2.easybeans.core_1.0.0
9ACTIVE org.ow2.easybeans.component.carol_1.0.0
10ACTIVE org.ow2.easybeans.component.hsqldb_1.0.0
11ACTIVE org.ow2.easybeans.component.jdbcpool_1.0.0
12ACTIVE org.ow2.easybeans.component.joram_1.0.0
13ACTIVE org.ow2.easybeans.component.jotm_1.0.0
14ACTIVE org.ow2.easybeans.component.quartz_1.0.0
15ACTIVE org.ow2.easybeans.agent_1.0.0
16RESOLVED org.ow2.easybeans.examples.osgi_1.0.0
17RESOLVED org.ow2.easybeans.examples.entitybean_1.0.0
18RESOLVED org.ow2.easybeans.examples.messagedriven_1.0.0
19RESOLVED org.ow2.easybeans.examples.migrationejb21_1.0.0
20RESOLVED org.ow2.easybeans.examples.security_1.0.0
21RESOLVED org.ow2.easybeans.examples.stateful_1.0.0
22RESOLVED org.ow2.easybeans.examples.stateless_1.0.0
23RESOLVED org.ow2.easybeans.examples.timer_1.0.0

Good luck and have fun with EasyBeans. In some days I'll report my experiences how to run EasyBeans and Eclipse Riena together.

this blog in german:

Eclipse Ganymede ante portas

2008-06-05T14:13:00.009+02:00

Same procedure as every year: a new Eclipse release is coming: Eclipse 3.4 (Ganymede). There's no other software project publishing every year a new release at the same day.

Since some weeks I'm working daily using the 3.4 Milestones and you should do the same: download the actual release candidate and test your environment.

Enhancements in Databinding, PDE Tooling and Equinox are most important for me - best you take a look at the "New and Noteworthy".

Something problematic is the new P2 - replacing the old Update mechanism. In 3.4 Eclipse - Installations can share a bundle pool. Loosing the external locations for bundles is hard for me, because I use them heavy.

Also using P2 in RCP applications is hard and still has some bugs. But from my opinion we should give P2 a chance - but there are hot discussions at PlanetEclipse.
blog in german

about this blog

2008-05-28T09:16:00.004+02:00

in the past I blogged only in german, but there were always people asking for an english translation. so I have decided to blog in both languages: in german at http://ekkes-ecke.org and all the technical stuff also in english here.
ekke