Model attributes and default values
by Alessio Soldano
Hi,
QA has been testing various value transitions on the attributes in the
webservices subsystem of the model and found something unexpected for
attributes with default values. I had a look and found that when running
the following commands:
/subsystem=webservices:undefine-attribute(name=modify-wsdl-address)
reload
/subsystem=webservices:undefine-attribute(name=modify-wsdl-address)
for the last command the
WSServerConfigAttributeHandler#applyUpdateToRuntime method is passed
true as resolvedValue and undefined as currentValue. The resolvedValue
being true is because of the default value for that attribute being
true, but is it correct to get undefined as currentValue in that case?
Do I have to manually figure out there's a default value for the
attribute and hence decide nothing was changed if currentValue is
undefined and resolvedValue equals default value... or is there's a
specific way to deal with this scenario?
Thanks
Alessio
--
Alessio Soldano
Web Service Lead, JBoss
9 years, 7 months
Transaction subsystem dependencies
by Tristan Tarrant
Hi all,
I'm reworking the Infinispan Server package so that it is built around
WildFly Core as I want to keep it as lean as possible.
I need to pull in a couple of additional subsystems from WildFly proper
and one of them is causing some head-scratching: the transactions
subsystem. It has a bunch of hard dependencies on a ton of modules which
really sound optional. Examples:
- the IIOP stuff
- Narayana compensations (JAX-WS, JAX-RS, Servlet API, Weld)
- HornetQ
None of the above are really needed by Infinispan Server. I guess I
could apply manual surgery to the module.xml file to remove stuff I
think is unnecessary and let my testsuite verify if I'm being too
aggressive, but I was wondering whether it would be better for the
upstream project to be a bit more careful with the dependencies.
Thanks for any suggestions
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
9 years, 7 months
Remove Xalan?
by Carlo de Wolf
We are keeping a (old) fork around for Xalan. Now and then the question
pops whether we can backport more from upstream. Rather I want to rid of
it at all as I don't want to maintain forks of third party projects and
I don't see Xalan releasing soon with anything we would upstream.
Can we remove Xalan? (Maybe we have some weird dependency on specifics.)
What should be its replacement?
Filed https://issues.jboss.org/browse/WFLY-4704 to note any decisions.
Carlo
9 years, 7 months
Moving component projects to a "feature pack" model?
by Sanne Grinovero
# WHAT WE DID SO FAR (and worked quite ok)
Since a couple of years, when releasing Hibernate Search, Hibernate
OGM, Infinispan and other projects, besides merely uploading our jar
and pom.xml files to Nexus we also upload a large tarball containing
modules for WildFly: an "add on layer", not only useful for end users
but also some other projects rely on this (e.g. Infinispan consumes
the Hibernate Search one to keep an aggressive improvement pace).
With each build of the projects these modules are not just built but
also tested: integration tests download the latest stable WildFly
version which we target, untar it, untar our own modules as a layer,
run some Arquillian tests. Invaluable to get all dependency
definitions and classloading right!
# GOALS
-- to make sure people can download our latest release, and it will
work on their favourite app server
-- to be ready knowing how a stable module structure should be
shaped, when a new version of WildFly integrates our latest
-- to benefit from the modules system by allowing different versions
to co-exist on the same appserver (some people/project/product require
this)
# NOT PERFECT
This second goal had some issues recently, namely that while we know
how we should structure the modules within WildFly, it happened that
this wasn't re-creating exactly the model of what had been carefully
tested within our project. The problem is that we have to repeat the
build scripting - result might not be identical for obvious reasons -
while most integration tests reside within the project.
# FEATURE PACKS
Tomaz was so nice to show me how to define feature packs, so that the
WildFly build can - at build time - include the structure we define.
It looks very promising, but on some areas we'll need some suggestions
or perhaps a further evolution?
# NEEDED IMPROVEMENTS / SUGGESTIONS
? How do we test the feature pack ?
The goal of having WildFly use the module structure that we build
"verbatim" is only interesting if we make sure these packs work
correctly.
Ideally we'd like to deploy them in Arquillian tests like we did with
modules, and run integration tests on each commit.
? How can end users benefit from these ?
We'd really want to enable our pool of users and contributors to use
(and test!) any of our releases from "day zero".
Typically people will want to run it on the latest stable version of
WildFly, which implies something releases before "day zero".
? Versions and slot identifiers ?
We release approximately every three weeks on average, and our slot
conventions expect that "our" module releases use the
slot={releaseVersion}, while the module included in WildFly has the
slot="main".
This seems to imply some need for slot transformations when the
feature pack is consumed.
? Aliases ?
We also include module aliases for each Major.Minor combination for
the public-api module, which resolves to the latest major.minor.micro
of the matching version.
This is important to make sure we can include references to module
dependencies maintained in other projects but limiting the scope to a
compatible range, for example we have an optional dependency on
Infinispan, not all Infinispan versions are compatible.
My preferred solution would be to have WildFly actually not use "main"
slot internally, but use our same alias pattern and in addition have
an alias module - for the public API only - which has slot "main"
resolve to the "major.minor" of the Hibernate Search version which was
included.
There are many benefits to this model, I'll avoid repeating them in
this email; I shared some thoughts before:
- http://lists.jboss.org/pipermail/wildfly-dev/2015-April/003787.html
I would love it if a similar pattern was to be applied to other
modules, for example Hibernate Search doesn't work with any version of
Hibernate ORM so depending on "slot main" has some dangers. Even more
important when we deal with other modules released by other projects
in similar packaging.
? "System" modules ?
I noticed the feature pack structure includes the path to the module layer, i.e.
modules/system/layers/base/..
But I take it we don't want to classify our "independently" released
modules as belonging to the system/base layer?
? Conflicting versions ?
I noticed the versions of all dependencies are listed once, in the
root metadata of the feature pack. In some projects, like Hibernate
OGM, we take strong advantage of modularity and actually bundle some
libraries multiple times - of different versions - and use the modules
magic to keep them strictly isolated.
Is this going to be possible?
Thanks in advance for any suggestions!
Sanne
9 years, 7 months
WildFly Core 1.0.0.CR5 released
by Brian Stansberry
It's Friday so it's time for another WildFly Core weekly release. This
time it's 1.0.0.CR5, which has been integrated into the 9.x branch of
WildFly for use in the 9.0.0.Final release.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
9 years, 7 months
datasource:installed-drivers-list()
by Heiko Braun
What’s the expected output of the installed-drivers-list() operation in the domain? What drivers should it be listing?
a) any driver: no matter wether it’s a module or deployment
b) any driver installed as a module
c) any driver resource declared under subsystem=datasources/jdbc-driver=*
d) a combination of any of the above
/Heiko
9 years, 7 months
WildFly Core Moving to Java 8
by James R. Perkins
Assuming the master-ignore jobs pass I'll be moving WildFly Core to
require Java 8. Note that you'll likely see more compile warnings. We'll
work on cleaning those up as we go but if you feel the desire to help
out please keep commits small and concise.
This is your 4 (maybe more like 30) minute notice.
--
James R. Perkins
JBoss by Red Hat
9 years, 7 months
