Regarding Jakarta EE 10 implementation of BIRT to work with wildfly 27

[kranthirathikanti]

Hi Team,

We have been using the eclipse BIRT in our product and we are planning to support wildfly 27 to our product and which is a Jakarta EE 10 implementation. As part of this support, BIRT also need to be with Jakarta EE 10 implementation. It seems that the latest version of eclipse BRT (4.12.0) doesn't have the Jakarta EE 10 implementation. Could you please let us know if you have a plan for this implementation ? if so, any timeline.

[brivalin]

Hello there,

To add some additional informations, what I saw not working on Jakarta EE 10 at this moment is the Viewer Tag Library.

When trying to deploy a project including the "viewerservlets.jar" with tag library enabled, it runs into lots of "java.lang.NoClassDefFoundError" exceptions.
By example the first one looks like :

WARN [org.jboss.modules.define] (MSC service thread 1-1) Failed to define class org.eclipse.birt.report.taglib.AbstractBaseTag in Module "xxx.war" from Service Module Loader: java.lang.NoClassDefFoundError: Failed to link org/eclipse/birt/report/taglib/AbstractBaseTag (Module "xxx.war" from Service Module Loader): javax/servlet/jsp/tagext/TagSupport

And finally, the deployment ends with :

WARN [org.jboss.as.ee] (MSC service thread 1-1) WFLYEE0007: Not installing optional component org.eclipse.birt.report.taglib.ParamDefTag due to an exception

The new Jakarta EE 10 specifications replaced all "javax" package namespaces by the "jakarta" one that I think causes all of these java.lang.NoClassDefFoundError exceptions.

[kranthirathikanti]

Thank you for your time and response.

Yes, you are right.

So, viewerservlets.jar jar should implement "jakarta" namespace in order to support Jakarta EE 10.

Thanks,
Kranthi

[wimjongman]

Thanks for the analysis. Can you provide a patch? The Contribution Guide is here.

[dzorwulu]

Hello Team
Please what is the status of this issue? In BIRT-runtime-4.13.0 classes in viewservlets.jar still have 'javax' imports instead or 'jakarta'. This is breaking our app server with java 17.

[wimjongman]

We have not worked on it. Please, members of this discussion, provide a patch. The Contribution Guide is here.

[claesrosell]

I would just like to note that we currently are using Jetty10, which some parts of the Eclipse 2022-12 release rely on. A move to the jakarta namespace would require us to use Jetty11 instead.

I have, in principle, nothing against this, but it would probably require us to maintain two separate branches of BIRT since the javax namespace is far from dead.

Some of the tools we are using, like axis 1.4, rely on the javax namespace. We probably would need to move away from those.

[dzorwulu]

Thanks for the prompt response
'javax' name is proprietary and belongs to Oracle. 'jakarta' is the replacement open-source name for all 'javax' named packages.

Oracle JDK road & LTS
https://www.oracle.com/java/technologies/java-se-support-roadmap.html#:~:text=Support%20for%20JavaFX%20on%20Java%20SE%208%20will%20continue%20until%20March%202025.&text=*%20Oracle%20Java%20SE%20product%20dates,up%2Dto%2Ddate%20information.

Axis2 1.8
https://axis.apache.org/axis2/java/core/release-notes/1.8.0.html

regards

[speckyspooky]

@wimjongman , @claesrosell , @merks

Short note: the report viewer isn't moved currently to "jakarta".
The current build re-mastering will be done with JDK17.

Please correct my interpretation, in my understanding the viewer should be moved
to "jakarta" before we publish the new BIRT-release 4.14 under JDK17.

[merks]

I imagine moving to Jakarta might be a significantly time consuming process and it's not at all clear that all your libraries/dependencies can even accommodate that! Furthermore, I don't see that building with Java 17 is in any way related to Jakarta. The JDK does not contain, use, nor provide anything from the jakarta namespace nor will it ever do so, so there is no relation.

[speckyspooky]

Sounds good for me. In my mind the usage of JDK17 is directly combined with the module handling and the removed javax from java-core.
So it seems to be build with the existing Java-references.

[merks]

No, modules kicked in for Java 9 and only parts of javax were migrated to jakarta, i.e., only the JEE things. So not to worry of course eventually one will want to migrate. But I would plan for such a thing at the start of a release cycle. Even the Eclipse Platform itself is only in early stages of such migration...

[dm-ion]

Hi, it is not exactly "clean" but for your information we are running BIRT within a Jakarta project on tomcat 10.x without issue. We use the BIRT engine and BIRT web viewer within our web application to run a variety of different reports. We certainly do not use all of the features that BIRT exposes, so this may not work "everywhere" or for "everything".

We accomplished this by using the tomcat translator to automatically translate all of the BIRT jars to Jakarta. In terms of third parties it was mostly okay, but we did have to also translate axis and make one api change there for Servlet 6.

There are some other peculiarities to our build as well, such as not using OSGI, subbing in maven central artifacts for the orbit ones where we can, some other dependency upgrades, etc. In addition the tomcat translator does other undesirable things to your jar files, such as stripping signatures.

Certainly would be some work to convert BIRT to Jakarta upstream. Simply commenting for anyone who needs to run BIRT on Jakarta sooner, it's certainly possible.

[wimjongman]

Thanks for the feedback @dm-ion. It is encouraging.

[ipanera]

Hi, it is not exactly "clean" but for your information we are running BIRT within a Jakarta project on tomcat 10.x without issue. We use the BIRT engine and BIRT web viewer within our web application to run a variety of different reports. We certainly do not use all of the features that BIRT exposes, so this may not work "everywhere" or for "everything".

We accomplished this by using the tomcat translator to automatically translate all of the BIRT jars to Jakarta. In terms of third parties it was mostly okay, but we did have to also translate axis and make one api change there for Servlet 6.

There are some other peculiarities to our build as well, such as not using OSGI, subbing in maven central artifacts for the orbit ones where we can, some other dependency upgrades, etc. In addition the tomcat translator does other undesirable things to your jar files, such as stripping signatures.

Certainly would be some work to convert BIRT to Jakarta upstream. Simply commenting for anyone who needs to run BIRT on Jakarta sooner, it's certainly possible.

Hi @dm-ion.
They are goog news that we are glad to ear because we have the same issue.
It could be nice if you could share more about your changes and pom files with us.
Greetings

[ahsin019]

We are trying to migrate it to use EE10, but found out ViewerServlet/ViewerServletContextListener in 4.14.0 still use

javax.servlet.ServletConfig;
javax.servlet.ServletException;
javax.servlet.http.HttpServletRequest;
javax.servlet.http.HttpServletResponse;
javax.servlet.ServletContextEvent
javax.servlet.ServletContextListener

https://github.com/eclipse-birt/birt/blob/master/viewer/org.eclipse.birt.report.viewer/birt/WEB-INF/classes/org/eclipse/birt/report/servlet/ViewerServlet.java

Any plan to to replace above with jakarta?

[speckyspooky]

Yes, the replacement is planned, but won't be upcoming directly with the next release
because there are lot of more dependencies which we would have to change if we switch to Jakarta EE.

[ahsin019]

Thanks @speckyspooky

Any time frame we can expect BIRT to be compatible with Jakarta EE 10? Especially since everybody is forcing "java 17" aka.. spring etc.

[roeltje25]

This is really something I would consider priority 1 above all else. Everyone has been on Jakarta EE for some time now, BIRT is simply not runnable on wildfly above version 26 e.g. Any input on what priority you guys are giving this?

[wimjongman]

Hey Roel, we prioritize it, but we are all unpaid volunteers. If Upsilon would like to sponsor this, please contact me. I can make a quote and work with the BIRT developers to make this happen.

[speckyspooky]

@roeltje25 Some additional information. Your note isn't correct at all.
Because the runtime of BIRT is runable with WilfFly above version 26.

In my product I use WildFly 29 upcoming is WildFly 30 und I use the OSGI runtime of BIRT 4.13 (4.14 upcoming) and all is fine.
Yes, I use only the runtime engine and not the UI-web feature on product side where the main changes must be done.

[speckyspooky]

Latest update on it BIRT 4.14 is working with WildFly 30.0.1

[cusmelee]

I found this on youtube, just for reference: https://www.youtube.com/watch?v=bO3_pjuSjYQ
How to Easily Upgrade to Jakarta EE 10 Javax to Jakarta Prefix without a Hassle

[Girish-tech1]

Has anyone tried using https://tomcat.apache.org/download-migration.cgi to migrate BIRT code to work with Jakarta EE?
Is this recommended by BIRT team

[saumya2907]

I still see javax namespace in the coreapi 4.16 version
https://github.com/eclipse-birt/birt/blob/master/core/org.eclipse.birt.core/src/org/eclipse/birt/core/framework/PlatformServletContext.java

is this going to be replaced by jakarta soon?

[Jokerinout]

Hi, it is not exactly "clean" but for your information we are running BIRT within a Jakarta project on tomcat 10.x without issue. We use the BIRT engine and BIRT web viewer within our web application to run a variety of different reports. We certainly do not use all of the features that BIRT exposes, so this may not work "everywhere" or for "everything".

We accomplished this by using the tomcat translator to automatically translate all of the BIRT jars to Jakarta. In terms of third parties it was mostly okay, but we did have to also translate axis and make one api change there for Servlet 6.

There are some other peculiarities to our build as well, such as not using OSGI, subbing in maven central artifacts for the orbit ones where we can, some other dependency upgrades, etc. In addition the tomcat translator does other undesirable things to your jar files, such as stripping signatures.

Certainly would be some work to convert BIRT to Jakarta upstream. Simply commenting for anyone who needs to run BIRT on Jakarta sooner, it's certainly possible.

Hi, for information we succesfully make Birt working with tomcat10.0.0 (Jakarta EE 9) only using the tomcat translator to automatically translate all of the BIRT jars to Jakarta, this one : https://tomcat.apache.org/download-migration.cgi

[cusmelee]

@Jokerinout does it work with BIRT Viewer?