java.lang.NoClassDefFoundError: javax/xml/rpc/encoding/TypeMappingRegistry when starting WebViewer

[claesrosell]

There are currently problems with the WebViewer in Master. As seen here: #1447 (comment)

[claesrosell]

We had problems with the javax.xml.rpc-api packages when moving to JavaSE-11 a couple of years ago, which ultimately introduced our own version of that dependency. If I recall correctly it had something to do with the OSGI-headers of the Maven version of javax.xml.rpc .

We recently moved away from our own, modified, version of xml-rpc. We need to investigate if this problem is related to those changes.

[merks]

Could someone remind me how to "start the web viewer"?

I see "powered by jetty 10.0.15" in the picture...

[hvbtup]

In the report design perspective, with an open report, select Run / View report as ... anything from the menu.

[merks]

It seems you guys see more than I see. This is all I see with my partial non-functional migration to jetty 12:

This is with this in my workspace:

master...merks:birt:issue-1447

The "missing" class is in my workspace

And both versions are in the launched IDE:

[speckyspooky]

Have yu an suggestion how I can support you.
I'm not the expert of the final depencencies but if I can help you please let me know.

I checked the latest changes and I don't know if it has an effect but with PR #1451 the javax.xml.rpc version (seems to be a duplicate was deleted).
I can only see a small difference to the current rpc-version and the deleted version which is the bundle version - deleted version was 1.1.2 and the current orbit version is a 1.1.0.

@claesrosell
I can see that there was a special .classpath-file on the old (dropped) rcp-version.
Is there a relation to our current classpath issue?

Old file & comment

[merks]

Note that the old BIRT version packaged some jars (goodness knows where they came from) into a bundle and that bundle put those jars on the classpath.

It's javax.xml-rpc-api bundle that should be used now, not the very very very old java.xml.rpc bundle. The rpc-api is at version 1.1.4. This bundle is provided, as the Plug-in Name suggested, by the Jakarata project and is the most recent version.

I too want to help, but it seems to me as long as we are pulling in a Jetty 10 stack and trying to get that to work on top of the Platform's Jetty 12 dependencies, we are highly unlikely to be successful. I.e., I still don't understand how this issue is different issue 1447...

[claesrosell]

Sorry, I am confused.
Is the current state of master using the 4.30 version of the platform?

[merks]

It is confusing.

The target in master is using 4.29:

birt/build/org.eclipse.birt.target/org.eclipse.birt.target.target

Line 344 in 5c22cbe

<repository location="https://download.eclipse.org/eclipse/updates/4.29/R-4.29-202309031000"/>

But that's just to make the builds work.

If you try to install that build into 4.29 2023-09, the IDE doesn't even start.

That is the reason for the prototype PR I created for you. So on master the setup is like this:

If you double click it opens the properties view and that needs to be 2023-12 for 4.30 in the target platform.

I think it's futile to try to get 4.29 to work.

If you change it and do Perform Setup Tasks, you'll see it used 4.30 and then will update the target platform to that:

In the prototype branch it should be that way already.

[merks]

I'll be traveling to EclipseCon so will be slow to answer questions...

[speckyspooky]

So currently we have a real mixed dependency situation labeled with 2023-09 (4.29) but used internally 2023-12 (4.30).
If we would have a full rollback to the status before we would be able to create the planned release.

But if I understand it correctly this is not possible and so the are stuck in without anaother option till Jetty 12 may by is changed. Which is hard for the further planning. So I stopped my internal roadmap competely because we don't know when it will be fixed.

[merks]

Yes, this is the rock and the hard place problem. Roll back all the commits is of course possible. But all the work around such activity is strictly volunteer for me and a rollback approach generates one heck of a lot of work that no one else seems to be able to manage. My schedules are not completely free to accommodate such things. E.g., this is EclipseCon week so I really actually have time for thing. In the end, releases need better planning than "oh, I think we should release now."

It's all a bit of cluster foobar here with the Platform migrating to Jetty 12, but the Jetty project no having all the necessary parts in place. I could just scream: 😱

[hvbtup]

I know this doesn't help others, but I just want to say that it is "only" the Web Viewer which is not working.
The BIRT runtime (when integrated via API and not via the viewer servlet) is working fine for me.

And while I'm not able to help with these build issues, be assured I know how hard you are working and I cross my fingers you will make it work in the end.

[merks]

Yes, the fact that the tools all work well is a saving grace. To a large extent this is the case because there are lots of good tests for that functionality and those tests all run as part of the build. Whatever isn't tested is easily broken...

If we can get the web viewer functionality to a point where something sort of starts to work or at least fails is some visible way, then I can help, as I did for Equinox a few weeks ago:

eclipse-equinox/equinox@1a51ae9

But the state in the following "prototype PR" is such that it quietly just doesn't work at all, so I have no idea where to look:

#1448

It's been suggested that the missing ee8 bundles are relevant and important, so hopefully that's the case and will be addressed relatively soon. The work on the ee8 support suggests that a release containing that could be available in about 3 weeks so ideally the Platform will be using such a newer Jetty 12 version.

We all appreciate very much @claesrosell efforts to help on this front!

[speckyspooky]

@hvbtup
From my point of view it is very simplified to say "only" the web viewer.
I don't know in which way you will test from eclipse designer because all emmitters cause currently the 500-error.
So e.g. on eclipse: if I select PDF and get directly 500-Error, if I select XLSX and get 500-Error.
In this case independent whether the viewer is integrated or not we haven't an option to test & develope the reports.
Therefore I would say, it is not "only an Viewer" issue.

Good tho know is the fact that the BIRT-runtime is running!
Next good topic I was able to test some Excel-reports with the new apache POI 5.2.x and the reports was running with your changes @merks .

[merks]

At least we have some good news. It's remains upsetting to be in a state that is not fully functional.

In any case, I'm also making sure that the Platform does not lock a specific version of Jetty bundles such that we will be in a better position to test and use new Jetty 12 versions that become available:

eclipse-platform/eclipse.platform.releng.aggregator#1444

[claesrosell]

I stumbled upon this issue when I was working with the Jetty-12 migration. The cause is that there are missing dependencies between the Axis bundle and java.xml.rpc.

These needs to be added:

 javax.xml.rpc.encoding;version="1.1.0",
 javax.xml.rpc.handler;version="1.1.0",
 javax.xml.rpc.handler.soap;version="1.1.0",
 javax.xml.rpc.holders;version="1.1.0",
 javax.xml.rpc.server;version="1.1.0",
 javax.xml.rpc.soap;version="1.1.0",

We currently seem to have access to two versions of Axis, one in the source tree at common/org.apache.axis and another one via Orbit. I guess that we should try to get the Orbit version updated.

[dm-ion]

Hi, if you are considering updating Axis to the latest Snapshot I have a suggestion.

AxisServlet.doGet uses a deprecated method (line 265) that has been removed in the latest servlets.

String url = HttpUtils.getRequestURL(request).toString();

This means that likely the BIRT viewer will not work when run with the Jakarta namespace if you auto-migrate it (eg: using Tomcat's tool) unless you replace this method with something else.

[claesrosell]

I just wanted to correct myself. The Orbit version of Axis seems to have the correct Import-Package: headers. For some reason the wrong bundle was picked during debug, even if I am sure that I had excluded it from the launch -config.

[merks]

Unfortunately there are quite a few duplicates floating around. I'm hoping that with m2 done on Friday that there will be better alignment on the newer/latest bundles from Orbit (which I have been testing to ensure they work well with BIRT)...