WildFly Calendary Proposal
by Jason Lee
I have a PR open that is a first step in creating a calendar of
WildFly-related events: https://github.com/wildfly/wildfly.org/pull/439
Brian does a great job of emailing the WF dev schedule to this list, but,
for me, it tends to get buried and lost. What I'd love to be able to do is
subscribe to a .ics and have events show up on my calendar. This is a step
toward that. What would be nice is to take that one step further and make
it available in a human-friendly form on wildfly.org as well.
All that said, I would love feedback on the idea itself, the contents of
the calendar, etc. to see if this would be useful to more than just myself.
Additionally, I know we have various community efforts going on at the
moment, so if this overlaps with any of that, I'm happy to roll this into
those efforts.
Jason Lee
Principal Software Engineer
Red Hat JBoss EAP
3 months
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
9 months, 4 weeks
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
11 months
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
11 months
