WildFly 33 Schedule
by Brian Stansberry
We're aiming to have WildFly 33.0.0.Final available on wildfly.org on
Thursday, July 18. The beta should be available on July 4.
Following are the key dates:
Wed Jun 26 -- Feature Freeze
Mon Jul 1 -- WF Core Beta release
Wed Jul 3 -- Tag/deploy 33 Beta
Thu Jul 4 -- Announce release
Wed Jul 10 -- Final PRs due
Mon Jul 15 -- WF Core Final release
Wed Jul 17 -- Tag/deploy 33 Final
Thu Jul 18 -- Release available on wildfly.org
Fri Jul 19 -- Post release deliverables
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
5 months, 1 week
Deprecate Apache CXF Aegis databinding in the future
by Jim Ma
CXF Aegis databinding is possibly deprecated and removed in the future CXF
release.
I am not sure if there are WFLY users who are still using this feature now.
If you have any comments and concerns about this change, please let us know.
Thanks,
Jim
6 months, 2 weeks
WFLY-19020: behavior change in persistence unit handling of application client
by Wolfgang Knauf
Hi all,
this question is about a change in the way that a JakartaEE application
client is launched: https://issues.redhat.com/browse/WFLY-19020
Before the change, an application client might receive a
ClassNotFoundException because of a missing hibernate class. My
workaround for this was to add jboss-deployment-structure.xml and
include the module "org.hibernate".
This behavior was changed in 31.0.1 after my bugreport: it seems the
application client deploys "persistence.xml" from the EJB jar somehow,
and my sample now works.
But this change also causes the application client to create/drop the
tables each time it is launched if persistence.xml defines
"hibernate.hbm2ddl.auto=create-drop". This did not happen with WildFly
31.0.0 and before.
It can be avoided if the data source in "appclient.xml" points to a H2
memory database instead of the real database defined in "standalone.xml".
I did not verify whether old WildFly versions required the datasource to
be defined in "appclient.xml", but I have the feeling that it was necessary.
Currently, this is only an unnecessary step. But if the datasource
defined in "appclient.xml" would point to the "real" datasource defined
in "standalone.xml", the tables would be created each time the client
starts. Fortunately, I could not make it work to define a MariaDB
connection in "appclient.xml" because it could not resolve the driver,
but with some effort this could be possible.
What do you think about this change? To me, it sounds unnecessary to
create/drop tables from EJB "persistence.xml" when an app client is
started. Is it required if the app client itself would use client side JPA?
Best regards
Wolfgang
6 months, 2 weeks
