| BPEL || org.eclipse.smila.processing.bpel.PipeletManager || debug || Log BPEL request XML before and after pipelet invocation. Note: this contains the XML for the records but only their filtered version.

+

| BPEL || org.eclipse.smila.processing.bpel.activities.PipeletManager || debug || Log BPEL request XML before and after pipelet invocation. Note: this contains the XML for the records but only their filtered version.

Probably you did forget to copy build.properties.template to build.properties in SMILA.builder and adapt it. See
How to build SMILA.

Launching SMILA

Linux

How to start/stop and manage SMILA as a background process on a Linux machine?

Since the default configuration (stored in SMILA.ini) of the OSGi runtime (in our case Equinox) launcher expects that you execute it in foreground and therefore have an OSGi console running in your shell and listening to the standard input, the first thing we have to do is to advise the launcher (and thereby Equinox) to listen on some TCP port instead. This is done by adding a new line with the port number just after the "-console" line.

For example, to set console to listen at TCP port 9999, SMILA.ini would look like this:

-console
9999
...

Now, after SMILA has been started with “$ nohup ./SMILA &”, the console can be accessed from any computer simply by opening a telnet session:

$ telnet <smila_host_name> <console_port>

If you are logged in via telnet and just want to close this connection and not to stop Equinox running SMILA, than just type “disconnect”. Otherwise, if you want to stop SMILA and close the connection, use “close” - as you normally would do on a console running in your shell.

OSGI-Services

I implemented/deployed an OSGi Service but it seems that it isn't activated

Check your bundle, it should contain a file like that:

OSGI-INF/<myService>.xml

In this file your service has to be referenced. If you have copied the file from some other service, be sure to change the component name in the root element to something unique, because DS does not start multiple services with the same component name.

<component name="<myService>" immediate="true">

Also the file has to be referenced in the META-INF / MANIFEST.MF file of your bundle as a service component:

Service-Component: OSGI-INF/<myService>.xml

On the "Build" page of the manifest editor, you must add the OSGI-INF directory to the binary build.

And finally, your bundle has to be started at SMILA launch, by adding it to the configuration/config.ini:... <bundle-id>@4:start, \...

If you are using SMILA.launch to launch SMILA in eclipse IDE, you have to open the run/debug configuration of SMILA, check the new bundle and set Auto-Start to "true".

If you checked all the things above and it still doesn't work:

Implement an activate() method in your service - if not already there, and check if it's called at startup.

If your service depends on other services, check if those are activated

If your service uses other services, check the naming of the set/unset methods in the Java code vs. those specified in the <myService>.xml

If your services uses 3rd-party-jars, make sure that they are specified in the Bundle-ClassPath section of your MANIFEST.MF (Do not reference the lib folder here, instead reference all jars, e.g. Bundle-ClassPath: ., <lib1.jar>, <lib2.jar>). Make also sure, that they are added to the binary build ("Build" page of the manifest editor).

If your service has super-classes you may need to include Import-Package: declarations of the super-classes in your service implementation class even if there are no compile errors.

Use the OSGi console, e.g. via: telnet <host> 9005

ss <bundle-ID> - check if your bundle is in the list and ACTIVE (the bundle-ID is the "Bundle-SymbolicName" from the MANIFEST.MF)

if it isn't in the list, the bundle is not correctly deployed

if it isn't ACTIVE but only RESOLVED it's not started (-> see hints above)

bundle <id> - check if your service is listed here in the "Registered Services" section (the "id" can be taken from the "ss" output)

if it isn't there, your service is not correctly deployed (-> check all points above)

General

I get classloading errors when I try to access an external Web Service using JAX-WS

Class loading problems often occur when using third party libraries that use the "thread context classloader" in OSGi, and standard implementations of Java specifications by Sun/Oracle (or other non-OSGi-aware parties...) do this very often.

The only solution we currently know of is to wrap the critical section (in this case it's the construction of the webservice client class) in a piece of code like this:

More classloader errors

If you get an error like this:

Caused by: java.lang.LinkageError: loader constraint violation: when resolving field "DATETIME" the class loader (instance of
org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) of the referring class, javax/xml/datatype/DatatypeConstants, and the class loader (instance of <bootloader>) for the field's resolved type, javax/xml/namespace/QName, have different Class objects for that type

the reason is most likely that you have classes in the bundle classpath of your bundle that contains classes which are also part of the JDK runtime library (java.*, javax.*). Remove these classes from the bundle and it should work.