** if it says {{code|"mode": "STANDARD"}}, stop the job run ({{code|POST http://localhost:8080/smila/jobmanager/jobs/<job name>/<job run id>/finish}}) and start it again with mode "runOnce", e.g. {{code|POST http://localhost:8080/smila/jobmanager/jobs/<job name> {"mode": "runOnce"}}}

# ensure that the attributes are not filtered out, see [[SMILA/Documentation/HowTo/How_to_filter_and_access_record_data_in_BPEL]]

−

=== Lucene Indexing / Search ===

+

'''Helpful log points'''

−

+

{{CTable}}

−

==== How can I browse/search an existing Lucene index without SMILA (for debug purposes)? ====

+

| Area || id || level || Comment

−

+

|-

−

Try [http://www.getopt.org/luke/ LUKE]

+

| 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.

Open the file: <tt>configuration/org.eclipse.smila.search.datadictionary/DataDictionary.xml</tt>

+

−

* Check the <code>Constraint</code> entries for all fields: If a <code>Constraint</code> is set <code>required</code> and this field is set in your query, the query value ''must'' match the indexed value! (regardless of other fields)

+

−

+

−

Still problems? Try removing the workspace version of that file if it exists:

This error usually happens when no index has been build but the user tries to do the search (directly after installing SMILA) by calling the test search application. Prior to 0.5 M3 user gets in this case a long stack trace with the real cause of the problem at the end of it: <tt>org.eclipse.smila.search.index.IndexException: index does not exist in data dictionary [test_index]</tt>. This means that the test index named "test_index" has not been created yet. This can easily be done by starting a crawler or an agent. In 0.5 M3 we improved the error handling in search servlet so that only error messages are displayed and highlighted. (Stack trace can still be seen by simply clicking on "Details...".)

+

== Implementing Pipelets / OSGi Services / Bundles ==

== Implementing Pipelets / OSGi Services / Bundles ==

Line 188:

Line 205:

# <tt><SMILA>/configuration/<bundle-name>/<config-file></tt>

# <tt><SMILA>/configuration/<bundle-name>/<config-file></tt>

# <tt><config-file></tt> in the root path of the bundle jar-file

# <tt><config-file></tt> in the root path of the bundle jar-file

+

+

See [[SMILA/Project_Concepts/Simple_configuration_handler|Configuration Handler]] for more information.

=== Deploy / Launch ===

=== Deploy / Launch ===

Line 210:

Line 229:

And finally, your bundle has to be started at SMILA launch, e.g. by adding it to the config.ini.

And finally, your bundle has to be started at SMILA launch, e.g. by adding it to the config.ini.

+

+

If you are using '''<tt>SMILA.launch</tt>''' to launch SMILA, you also have to open the run/debug configuration of SMILA, check the new bundle and set Auto-Start to "true".

==== I get classloading errors in invocations of my own Pipelet when running SMILA outside the IDE. In the IDE it works ====

==== I get classloading errors in invocations of my own Pipelet when running SMILA outside the IDE. In the IDE it works ====

Line 227:

Line 248:

Thamks to Bogdan Sacaleanu for the solution. See this [http://smila.markmail.org/thread/sj4vhcikq2wndtdp thread in the smila-dev mailing list] for additional details.

Thamks to Bogdan Sacaleanu for the solution. See this [http://smila.markmail.org/thread/sj4vhcikq2wndtdp thread in the smila-dev mailing list] for additional details.

+

==== 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:

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

+

</source>

+

+

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.

+

See also [http://www.eclipse.org/forums/index.php/t/266362/ this forum thread].

[[Category:SMILA]]

[[Category:SMILA]]

Revision as of 06:38, 16 November 2012

This pages contains the frequently asked questions of the SMILA project.

General Hint: When you have problems during a SMILA launch / run, please have a look at the SMILA log file first. (<SMILA>/SMILA.log)

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.

Deploy / Launch

I implemented/deployed a OSGi Service in a new bundle but SMILA log says that it couldn't be found

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

OSGI-INF/<myService>.xml

In this file your new 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 from the MANIFEST.MF file of your bundle as a service component:

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

Also, you may need to include Import-Package: declarations for super-classes of your service implementation class even if there are no compile errors.

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, e.g. by adding it to the config.ini.

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

I get classloading errors in invocations of my own Pipelet when running SMILA outside the IDE. In the IDE it works

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 - part 1

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.