BIRT 4.14/4.15: OSGI-version is broken, BIRT service cannot be initialized, Tomcat/Catalina: java.lang.NoClassDefFoundError: org/apache/axis/AxisFault

[speckyspooky]

BIRT 4.14/4.15: OSGI-version is broken, BIRT service cannot be initialized, Tomcat/Catalina: java.lang.NoClassDefFoundError: org/apache/axis/AxisFault

[speckyspooky]

The problem is solved with PR #1561

[speckyspooky]

I was able to shrink the location of the issue. There is some library at "WEB-INF\lib" is currently missing which cause the problem.

[speckyspooky]

@merks
I investigated a lot of time to get a full analysis of the difference between BIRT-OSGI 202306 (ok) & 202312 (fail) based on a file-by-file analysis. The result is that we have lot of missing files and a partial strange versioning of some jar-files. We have older jar-file-versions in the WEB-INF-folder of 202312 in compare with 202306.

The good news I got the BIRT 4.14 OSG runable with file changing at the WEB-IF\lib-folder.

Could you please check if we can change the built-process to copy the according files to the lib folder according to my manual changes.

Manual actions:

• added: org.apache.axis_1.4.1.v20231107-0937
• added: org.apache.commons.discovery_0.5.0.jar
• changed to newer version: jakarta.xml.bind_2.3.3.v20221203-1659
• changed to newer version: javax.inject_1.0.0.v20220405-0441
• changed to newer version: javax.xml.soap_1.3.0.v201105210645
• deleted: javax.xml.bind_2.2.0.v201105210648.jar
• deleted: javax.inject_1.0.0.v20091030
• deleted: javax.xml.soap_1.2.0.v201005080501

Libraries missing to but not added:

• javax.annotation_1.3.5.v20230504-0748
• javax.el-api_3.0.3
• javax.servlet.jsp-api_2.3.3
• javax.transaction_1.1.1.v201105210645
• org.w3c.css.sac_1.3.1.v200903091627
• flute (but this is ok and confirrmed)

[merks]

There are things being done in various ant scripts (which always gives me cold shivers when I see that because these things to me are like write-only code that is unmaintainable).

I see this doing a search:

That search includes logged content in the build.log that's produced locally when I do a build locally:

I'll dig a bit deeper to see which ant scripts in particular are involved. Unfortunately there are also ant scripts that appear to be unused, which makes it even more challenging to know what needs maintaining and what would be best flushed down a toilet.

[merks]

I think this is where the Maven/Tycho build is calling out to ant:

birt/build/birt-packages/birt-runtime/pom.xml

Lines 54 to 88 in 7cd02fe

	<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-antrun-plugin</artifactId>
	<version>1.8</version>
	<executions>
	<execution>
	<id>clean</id>
	<phase>clean</phase>
	<configuration>
	<target>
	<ant antfile="build.xml" target="clean" dir="${basedir}" />
	</target>
	</configuration>
	<goals>
	<goal>run</goal>
	</goals>
	</execution>
	<execution>
	<id>package</id>
	<phase>package</phase>
	<configuration>
	<target>
	<ant antfile="build.xml" target="package" dir="${basedir}">
	<property name="BIRT_VERSION" value="${unqualifiedVersion}-${maven.build.timestamp}" />
	</ant>
	<attachartifact file="${project.build.directory}/birt-runtime-${unqualifiedVersion}-${maven.build.timestamp}.zip" type="zip" />
	</target>
	</configuration>
	<goals>
	<goal>run</goal>
	</goals>
	</execution>
	</executions>
	</plugin>
	</plugins>

So all the juicy parts are here with lots of */ things to copy arbitrary matching things form other places:

https://github.com/eclipse-birt/birt/blob/master/build/birt-packages/birt-runtime/build.xml

I see this in the log:

build-webviewer:
     [echo] D:\Users\merks\birt-master\git\birt\viewer\org.eclipse.birt.report.viewer, D:\Users\merks\birt-master\git\birt\build\birt-packages\birt-runtime-osgi\target\package\WebViewerExample
     [copy] Copying 165 files to D:\Users\merks\birt-master\git\birt\build\birt-packages\birt-runtime-osgi\target\package\WebViewerExample
     [copy] Copied 31 empty directories to 1 empty directory under D:\Users\merks\birt-master\git\birt\build\birt-packages\birt-runtime-osgi\target\package\WebViewerExample
     [copy] Copying 31 files to D:\Users\merks\birt-master\git\birt\build\birt-packages\birt-runtime-osgi\target\package\WebViewerExample\WEB-INF\lib
     [copy] Copying 508 files to D:\Users\merks\birt-master\git\birt\build\birt-packages\birt-runtime-osgi\target\package\WebViewerExample\WEB-INF
     [copy] Copying 2 files to D:\Users\merks\birt-master\git\birt\build\birt-packages\birt-runtime-osgi\target\package\WebViewerExample\WEB-INF\lib
     [copy] Copying 3 files to D:\Users\merks\birt-master\git\birt\build\birt-packages\birt-runtime-osgi\target\package
     [copy] Copying 1 file to D:\Users\merks\birt-master\git\birt\build\birt-packages\birt-runtime-osgi\target\package\about_files
     [copy] Copying 1 file to D:\Users\merks\birt-master\git\birt\build\birt-packages\birt-runtime-osgi\target\package

But from this it's not clear nor obvious from where the things being copied to WebViewerExample\WEB-INF\lib come.

I guess it's specified here:

birt/build/birt-packages/birt-runtime/build.xml

Lines 99 to 103 in 7cd02fe

	<target name="build-webviewer">
	<copy todir="${STAGE_DIR}/WebViewerExample/WEB-INF/lib">
	<fileset dir="${STAGE_DIR}/ReportEngine/lib"/>
	</copy>
	</target>

But I don't' know how that result in the logged entries I see, which would be much more helpful if they also included from where the files come...

Does this help you?

[merks]

FYI, I think these are examples of distracting garbage:

[speckyspooky]

The copy actions are coming with my understanding from the osgi-build.xml
The are some comments from last changes from the summer - we discussed it June 24, 2023 at #1347

And I think this is the position to add the copy of the files to the lib-folder.

[speckyspooky]

I figured out further details because we have all elements in our plugin-folder to get OSGi runable:

• added: org.apache.axis_1.4.1.v20231107-0937
  --> available: copy from the plugin-folder

• added: org.apache.commons.discovery_0.5.0.jar
  --> available: copy from the plugin-folder

• changed to newer version: jakarta.inject.jakarta.inject-api_2.0.1
  --> available: copy from the plugin-folder

• changed to newer version: saaj.jar or javax.xml.soap_1.3.0.v201105210645
  --> available: copy from the folder plugins\javax.xml.soap_1.2.0.v201005080501\lib
  --> the old version "javax.xml.soap_1.2.0.v201005080501" isn't working
  --> required: saaj.jar or javax.xml.soap_1.3.0.v201105210645

• deleted: javax.inject_1.0.0.v20091030

• deleted: javax.xml.soap_1.2.0.v201005080501

[speckyspooky]

I have changed the build.xml which copy the right files.
But I have no idea how I can get the built of the OSGi-Version locally to test it.

Also the copy of the library saaj.jar isn't realy good to use the version folder.
Because if it would changed then we have an issue again. So I woul prever another way or we can also use "javax.xml.soap_1.3.0.v201105210645" but this jar isn't given in the plugin-folder.

Why we have the older version "javax.xml.soap_1.2.0" instead of "javax.xml.soap_1.3.0" in our plugins...(?)

<copy todir="${VIEWER_DIR}/WEB-INF/lib">
  <fileset dir="${ENGINE_DIR}/platform/plugins">
    <include name="jakarta.xml.bind_*.jar"/>
    <include name="javax.wsdl_*.jar"/>
    <include name="org.apache.commons.logging_*.jar"/>

  	<!-- added -->
  	<include name="org.apache.axis_*.jar"/>
    <!-- changed: <include name="org.apache.commons.discovery_*/lib/*.jar"/>-->
    <include name="org.apache.commons.discovery_*.jar"/>
  	<!-- added -->
  	<include name="jakarta.inject.jakarta.inject-api_*.jar"/>
  </fileset>
  <fileset dir="${REPOSITORY_DIR}/plugins">
 	<include name="javax.xml.soap_*.jar"/>
  </fileset>
  <!-- added -->
  <fileset dir="${ENGINE_DIR}/platform/plugins/javax.xml.soap_1.2.0.v201005080501/lib">
  	<include name="saaj*.jar"/>
  </fileset>

  <flattenmapper/>
</copy>

[merks]

Sorry, thought I checked in the launchers in but I did not:

I'll put it on my TODO list to check-in m2e-based launchers so that anyone can easily do a local Tycho build without needing to learn how...

[merks]

In any case, you're on the right track it seems! 👍

[speckyspooky]

Yes, this would be great with the "Tycho build"!
I created a PR with the "build.xml" and afterwards I will see the result of the build (from server side)

[merks]

FYI, I have a launch configuration that I can check in as soon as it runs to completion locally so that you can more quickly test the build locally. I'll create a PR for it immediate, assuming it's fine...

[merks]

Given it has no impact on the build, I just went ahead and committed the launcher:

#1562

You'll find it here:

It produces a log file that you can look at after the build:

Hopefully that speeds up the process. It also lets you see what the build produces to help with authoring...