Migration to Jakarta EE

[bvfalcon]

Solves #1172

TODO: BiRT Viewer can be migrated after Axis2 migration will be completed

[merks]

Note that the *.target is generated. Making it correct by hand is kind of challenging because you might well remove things that are needed not directly by BIRT but by BIRT's dependencies.

Using the tool bar button to run this specific task will update the target platform:

The dependencies you are changing are particular complex and error prone because of the Platform's and WTP's dependencies on related things.

There's also a launch configuration for running the build locally:

That might help you iterate more quickly...

I'll try to find some time ASAP to check out your changes and see if I can help get the build workings (mostly getting the target platform correct) but I have to go out until mid afternoon.

[merks]

When I do resolve the modular target platform there are a fair number of errors in my workspace:

BTW, I assume you've set up the environment using the setup:

https://github.com/eclipse-birt/birt#create-a-birt-development-environment

It's hard to help if we don't have the same development configuration...

[merks]

@bvfalcon

If there's something I can do to help, please let me know.

[bvfalcon]

If there's something I can do to help, please let me know.

Thanks a lot for all, Ed.
Now this ticket is blocked only by AXIS 2 (link in first commit).

[merks]

FYI, I looked at axis2 here:

https://repo1.maven.org/maven2/org/apache/axis2/

There's a lot of stuff there!

I looked particularly at this too:

https://repo1.maven.org/maven2/org/apache/axis2/org.apache.axis2.osgi/

But there are a lot of dependencies (package imports) to track down to make that bundle happy.

Do you already have a sense of which artifacts will be needed in the end?

[bvfalcon]

FYI, I looked at axis2 here:
...
I looked particularly at this too:
...
Do you already have a sense of which artifacts will be needed in the end?

All published Axis2 artifacts are focused to old-style Java EE (<= 8 )and not compatible with Jakarta EE (>= 9.1). Support of Jakarta EE will be added only with this ticket. Only one component of BiRT (Web Viewer) uses Axis 2 and needs its migration to Jakarta EE.

Necessary steps for closing this ticket:

1. Closing Axis2 ticket with Jakarta EE support
2. Release Axis2 with new version, which includes changes from step 1
3. Produce OSGi Axis2 for released on step 2 version
4. Use Osgi Axis2 from BiRT Web Viewer

But for BiRT users, who do not use Web Viewer, migration BiRT to Jakarta EE is already possible. In my projects BiRT can be used with changes already done in this ticket.

[hvbtup]

Abstract: This is lengthy. The main point here is: If Axis2 and Jakarta EE is such a burden, should we think about throwing it away and replace it with a more modern approach?

From a bird (or BIRT user's) perspective, I'm wondering why a program like BIRT needs an XML WebService Framework like Axis2 at all?

I took a look at the code and searched for org.apache.axis in *.java files.
It seems Axis is only used by the "Web Viewer".

What exactly is the Web Viewer (I really don't know)?

Is it what I can call from the BIRT designer here:

Is it also related to the example servlet that ends up in birt.war?
Is it used at runtime?

The technology stack used by the Web Viewer ATM is about 25 years old (XML, JSP, TLD, Servlets etc) and I fear that in a few years only senior citizens (senior developers ;-) will be able to halfway understand and hardly maintain the code.

Looking at the Java code in Web Viewer where Axis is used, about 99% of it is auto-generated from some WSDLs.

From a security POV it seems dangerous at first glance that there is such a lot of deserialization, for example files like viewer\org.eclipse.birt.report.viewer\birt\WEB-INF\classes\org\eclipse\birt\report\soapengine\api\DataSource.java. Why is that necessary, e.g. why should it be necessary to deserialize a data source from a possibly untrusted source?
Certainly not for a parameter entry dialog alone. I really don't see any use in deserializing e.g. data sources in a viewer app.

Worst of all: Where is that WSDL? I don't find any *.wdsl find when I look at the BIRT repo.

The non-existence of the WSDL means that that the XML serde is an undocumented implementation detail, there is no public API for the web viewer except the URL parameters.

In summary, it may make more sense to analyze what the web viewer is actually needed for,
then bury it (including the documented API) and start from scratch with a newer technology stack (eg JSON, REST, OpenAPI) while trying to avoid some of the mistakes like the excessive "serde".

Personally, I'm not using things like a parameter entry dialog (or a browser-interface at all) at runtime.

What is needed is the ability to run the report directly from the BIRT designer with different parameters.

But for that purpose, from my POV, it would also suffice to have something similar to the "run configurations" that we have in Eclipse eg for Java command-line programs:
A simple configuration consisting of output format, name-value combinations for the report parameters, and emitter options.
That would make testing reports from within the IDE even faster, because one could have different run configurations for different test cases.

Maybe some BIRT users already have already developed something like that?

Features like "page navigation" and "export to (different format)" are certainly important for some users.
I don't know how this is implemented ATM, and I reckon that a lot of brain-power was invested here, but maybe this could be solved differently. My first idea in this regard is that the "run configuration" should contain a toggle for "interactive mode".
In non-interactive mode, the run configuration should use RunAndRenderTask to directly generated the output.
In interactive mode, the run configuration should use separate RunTask and RenderTask. It will then need a session (which is not really REST-like, but who cares?). First, the RunTask would create an *.rptdocument and create a session ID (and manage the session, including timeout handling), preferably in a JWT or similar. It would then render (part of) the rptdocument (I really never use RenderTask, but probably this class can handle things like "render only page 3 as HTML", see https://www.eclipse.org/forums/index.php/t/120397/) and include navigation. When navigating, the browser has to supply the session ID resp. the JWT to the server again.

Creating a JSON API and implementation would probably take 1-2 weeks of work for someone who is familiar with this kind of development and can ask some BIRT developer for help regarding the RE API.
I think that (a prototype for) the non-interactive run configuration could be developed in a few days by an experienced eclipse developer (which I am not).
Adding the interactive features will probably need one or more weeks of work, though.

To summarize, I guess this would take ~ 15 days of work without interactive mode and 25-30 days of work including interactive mode.
That's definitely too much for someone to do this in his/her leisure time, but not too much for a company to pay someone for it.

On the positive side, this would

• remove the depency on Axis2,
• remove the need of a full-blown web-server like Tomcat for testing reports from within the IDE (something like Java's equivalent to Python's SimpleHttpServer should suffice),
• remove the need for all this auto-generated code,
• reduce the complexity of the build process,
• remove the dependency on an ancient technology stack,
• introduce a documented, modern REST API

[merks]

+10

Eliminating axis entirely would be a great way to nip future cve problems in the bud.

[hvbtup]

BTW I looked at what would be the possible frameworks to implement a REST API with Java which could be used in conjunction with HTML/CSS/JS as a replacement for the Web Viewer. I really don't have any experience with REST programming in Java (and only very limited experience with REST programming in other languages), but to me it seems that there are basically two fashions: JAX-RS or Spring Boot.
While many people like Spring Boot, I think in our special case, we should try JAX-RS and the Eclipse Jersey reference implementation. It seems to be lightweight, has few dependencies, works with Java SE, with practically all web servers and with OSGI, and developing with it seems rather easy.
There are also maven plugins (unrelated to Jersey) which automatically generate OpenAPI specification from the Java sources.

This doesn't change anything about the fact that it would mean quite a lot of work and would be a breaking change.

[saumya2907]

@bvfalcon I see javax used in core also.
https://github.com/eclipse-birt/birt/blob/master/core/org.eclipse.birt.core/src/org/eclipse/birt/core/framework/PlatformServletContext.java
Is this also going to be updated as a part of the next release

[hvbtup]

I see javax used in core also.
https://github.com/eclipse-birt/birt/blob/master/core/org.eclipse.birt.core/src/org/eclipse/birt/core/framework/PlatformServletContext.java

I can't really help, but to me it seems that the class PlatformServletContext should be moved out of the core framework package and into a package that is actually dedicated to running BIRT as a servlet. It is used only here: https://github.com/eclipse-birt/birt/blob/master/viewer/org.eclipse.birt.report.viewer/birt/WEB-INF/classes/org/eclipse/birt/report/service/ReportEngineService.java#L306