Testing 1..2..3
by Brian Stansberry
Just a test of the list delivery; we’ve gotten a report of issues.
--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat
7 years, 7 months
Srcdeps in WildFly and WildFly Core
by Peter Palaga
Hi *,
this is not new to those of you who attended my talk on the F2F 2016 in
Brno. Let me explain the idea here again for all others who did not have
a chance to be there.
Srcdeps [1] is a tool to build Maven dependencies from their sources.
With srcdeps, wildfly-core can depend on a specific commit of, e.g.,
undertow:
<version.io.undertow>1.4.8.Final-SRC-revision-aabbccd</version.io.undertow>
where aabbccd is the git commit id to build when any undertow artifact
is requested during the build of wildfly-core.
[1] describes in detail, how it works.
The main advantage of srcdeps is that changes in components can be
integrated and tested in wildfly-core immediately after they are
committed to a public component branch. There is no need to wait for the
component release.
Here in the WildFly family of projects, it is often the case that
something needs to be fixed in a component, but the verification (using
bug reproducer, or integration test) is possible only at the level of
wildfly or wildfly-core. Engineers typically work with snapshots
locally, but when their changes need to get shared (CI, reviews) in a
reproducible manner, snapshots cannot be used anymore.
In such situations a source dependency come in handy: it is very easy to
share and it is as reproducible as a Maven build from a specific commit
can be. All CIs and reviewers can work with it, because all source
dependency compilation is done under the hood by Maven.
Developers working on changes that span over multiple interdependent git
repos can thus get feedback (i-tests, reviews) quickly without waiting
for releases of components.
Srcdeps emerged in the Hawkular family of projects to solve exactly this
kind of situation and is in use there since around October 2015.
When I said there is no need to wait for releases of components, I did
not mean that we can get rid of component releases altogether. Clearly,
we cannot, because i.a. for any tooling uninformed about how srcdeps
work, those source dependencies would simply be non-resolvable from
public Maven repositories. So, before releasing the dependent component
(such as wildfly-core) all its dependencies need to be released. To
enforce this, srcdeps is by default configured to make the release fail,
as long as there are source dependencies.
I have sent a PR introducing srcdeps to wildfly-core:
https://github.com/wildfly/wildfly-core/pull/2122
To get a feeling how it works, checkout the branch, switch to e.g.
<version.io.undertow>1.4.8.Final-SRC-revision-1bff8c32f0eee986e83a7589ae95ebbc1d67d6bd</version.io.undertow>
(that happens to be the commit id of the 1.4.8.Final tag)
and build wildfly-core as usual with "mvn clean install". You'll see in
the build log that undertow is being cloned to ~/.m2/srcdeps/io/undertow
and that it is built there. After the build, check that the
1.4.8.Final-SRC-revision-1bff8c32f0eee986e83a7589ae95ebbc1d67d6bd
version of Undertow got installed to your local Maven repo (usually
~/m2/repository/io/undertow/undertow-core )
Are there any questions or comments?
[1] https://github.com/srcdeps/srcdeps-maven#srcdeps-maven
Thanks,
Peter
P.S.: I will be talking about srcdeps on Saturday 2017-01-28 at 14:30 at
DevConf Brno.
7 years, 7 months
JDK 9 EA Build 170 is available on jdk.java.net
by Rory O'Donnell
Hi Jason/Tomaz,
*JDK 9 Early Access* build 170 is available at the new location : -
jdk.java.net/9/
A summary of all the changes in this build are listed here
<http://download.java.net/java/jdk9/changes/jdk-9+170.html>.
Changes which were introduced since the last availability email that may
be of interest :
* b168 - JDK-8175814: Update default HttpClient protocol version and
optional request version
o related to JEP 110 : HTTP/2 Client.
* b169 - JDK-8178380 : Module system implementation refresh (5/2017)
o changes in command line options
* b170 - JDK-8177153 : LambdaMetafactory has default
constructorIncompatible change,
o release note: JDK-8180035
*New Proposal - Mark Reinhold has asked for comments on the jigsaw-dev
mailing list *[1]
* Proposal: Allow illegal reflective access by default in JDK 9
In short, the existing "big kill switch" of the `--permit-illegal-access`
option [1] will become the default behavior of the JDK 9 run-time system,
though without as many warnings. The current behavior of JDK 9, in which
illegal reflective-access operations from code on the class path are not
permitted, will become the default in a future release. Nothing will
change at compile time.
Rgds,Rory
[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
7 years, 7 months
Speeding up WildFly boot time
by Stuart Douglas
When JIRA was being screwy on Friday I used the time to investigate an idea
I have had for a while about improving our boot time performance. According
to Yourkit the majority of our time is spent in class loading. It seems
very unlikely that we will be able to reduce the number of classes we load
on boot (or at the very least it would be a massive amount of work) so I
investigated a different approach.
I modified ModuleClassLoader to spit out the name and module of every class
that is loaded at boot time, and stored this in a properties file. I then
created a simple Service that starts immediately that uses two threads to
eagerly load every class on this list (I used two threads because that
seemed to work well on my laptop, I think Runtime.availableProcessors()/4
is probably the best amount, but that assumption would need to be tested on
different hardware).
The idea behind this is that we know the classes will be used at some
point, and we generally do not fully utilise all CPU's during boot, so we
can use the unused CPU to pre load these classes so they are ready when
they are actually required.
Using this approach I saw the boot time for standalone.xml drop from ~2.9s
to ~2.3s on my laptop. The (super hacky) code I used to perform this test
is at
https://github.com/wildfly/wildfly-core/compare/master...stuartwdouglas:b...
I think these initial results are encouraging, and it is a big enough gain
that I think it is worth investigating further.
Firstly it would be great if I could get others to try it out and see if
they see similar gains to boot time, it may be that the gain is very system
dependent.
Secondly if we do decide to do this there are two approach that we can use
that I can see:
1) A hard coded list of class names that we generate before a release
(basically what the hack already does), this is simplest, but does add a
little bit of additional work to the release process (although if it is
missed it would be no big deal, as ClassNotFoundException's would be
suppressed, and if a few classes are missing the performance impact is
negligible as long as the majority of the list is correct).
2) Generate the list dynamically on first boot, and store it in the temp
directory. This would require the addition of a hook into JBoss Modules to
generate the list, but is the approach I would prefer (as first boot is
always a bit slower anyway).
Thoughts?
Stuart
7 years, 7 months
Provisioning a server without some core modules
by Carlo de Wolf
I'm trying to provision a server with the
wildfly-server-provisioning-maven-plugin. The server needs some modules
defined in the core-feature-pack excluded, so I put up excludes in the
dependency management of the pom. However all modules seem to be
included regardless of the projects dependency management.
Is server provisioning ignoring dependency management? If so, I think it
is a bug.
If not, then how should it be done?
Carlo
7 years, 7 months
Sending PRs upstream instead of wildfly-security-incubator / ladybird
by Darran Lofthouse
We have a number of PRs working there way through the queues now with
the latest component upgrades / backports from ladybird to upstream but
from this point on all pull requests should be sent directly upstream
instead of going via the ladybird branches.
We still have some PRs against the incubator which we will continue to
merge and port over so those don't need to be resubmitted.
We will keep the ladybird branches up to date with upstream in case we
need to use them again but for the last week or so the PRs coming
through have required less coordination so we should be able to handle
changes individually.
Regards,
Darran Lofthouse.
7 years, 7 months
using <xa-datasource> and <data-source> with same driver and other related questions
by John Mazzitelli
I have a stupid question and two not-so-stupid questions.
1. I think I know the answer but I really just need confirmation.
Suppose I have this defined in standalone.xml:
<driver name="h2" module="com.h2database.h2">
<xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
<driver>
Notice it defines the XA datasource class.
I can share this with both a non-XA <data-source> and a XA <xa-data-source>, correct? So this is OK:
<datasource jndi-name="java:/foo">
<driver>h2</driver>
<datasource>
<xa-datasource jndi-name="java:/bar">
<driver>h2</driver>
<xa-datasource>
That's the stupid question.
2. Here a second question - what is the purpose of both "driver-xa-datasource-class-name" and "xa-datasource-class". The weird thing is the XML in standalone.xml uses "xa-datasource-class" but that seems to be the value of the attribute "driver-xa-datasource-class-name" - what is this xa-datasource-class ATTRIBUTE?
The docs are not clear here: https://wildscribe.github.io/Wildfly/10.0.0.Final/subsystem/datasources/j...
where it says:
* driver-xa-datasource-class-name The fully qualified class name of the javax.sql.XADataSource implementation module-slot The slot of the module from which the driver was loaded, if it was loaded from the module path profile Domain Profile in which driver is defined. Null in case of standalone server
* xa-datasource-class XA datasource class
3. Third question - what is this "jdbc-compliant" attribute used for? The docs don't indicate what it would actually be used for:
* jdbc-compliant - Whether or not the driver is JDBC compliant
If I am defining a JDBC driver, wouldn't you think it is JDBC compliant? :-)
Thanks.
7 years, 7 months
The future of the management console
by Harald Pehl
We're currently working on the next major version of HAL [1]. HAL.next will
include all features of the current management console plus many new features
such as macro recording, topology overview, better keyboard support and
PatternFly [2] compliance. See [3] for more details.
We're making good progress and have migrated all of the configuration and
half of the runtime screens to HAL.next. What's missing is the support for
patching and the remaining runtime UI. Our goal is to ship HAL.next with
WildFly asap. If you don't want to wait, I encourage you to try out HAL.next
today [4] and give us feedback!
I'd like to use this post to give you the chance to participate in the
future of the management console. We already have some basic ideas what
we would like to add to HAL.next, but we also want you to give us additional
input.
# Runtime Extensions / JavaScript API
As most of you will know both HAL and HAL.next are implemented in GWT.
For the current version there's a way to write extensions as GWT modules [5].
This is based on the concept of having compile time extensions provided as
maven dependencies. While this gives you full access to the HAL API, it's
often hard to get started for none GWT developers.
New features in GWT 2.8 like JsInterop [6] make it very easy to export parts
of your Java code to JavaScript. We've used this feature to provide a basic
JavaScript API. This can be used in the future to write runtime extensions
in JavaScript. A first draft is available at [7].
# Monitoring
The current management console has some limited monitoring capabilities.
We could improve and enhance these capabilities if this is something which
you want to have out of the box. However we don't want to turn HAL into
another monitoring tool. There are plenty of other tools and frameworks
which focus on monitoring.
# Macro Recording
We've built basic support to record macros in HAL.next. Behind the scenes the
DMR operations are collected and made available for replay. We could extend
this feature to be more dynamic if requested (variables, iterations, el al).
# What else?
It's your turn! What else do you want to see in HAL.next?
[1] https://github.com/hal/hal.next
[2] https://www.patternfly.org/
[3] https://github.com/hal/hal.next/#motivation
[4] https://github.com/hal/hal.next/#running
[5] https://hal.gitbooks.io/dev/content/building-blocks/extensions.html
[6] https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa...
[7] https://github.com/hal/hal.next/wiki/JavaScript-API
--
Harald Pehl
hpehl(a)redhat.com
7 years, 7 months
Weld 3 & Wildfly 11 integration - help with security needed
by Matej Novotny
Hello,
recently I decided, that Weld 3 (CDI 2.0, currently nearing Final at high speed) should be running on WildFly 11.
Up until now, we had the integration based on 10.1.0.Final but for several reasons we want to move to 11.
There were some changes and I figured out most of them but I am lost when it comes to security.
I know Elytron was added but I don't know a damn thing about it - could anyone lend a hand here, please?
The code is now located at this branch[1] and the very last commit shows the integration done.
Vast majority is just taken from previous integration with 10.1.0.Final (branch 10.1.0.Final-weld3).
The part I am concerned about is weld/subsystem/src/main/java/org/jboss/as/weld/services/bootstrap/WeldSecurityServices.java [2]
'getPrincipal'[3] method was earlier adapted to Elytron, and I am thinking the other methods should perhaps be adjusted as well?
But then again, I have no idea how to do that with Elytron... a penny for your thoughts?
Regards
Matej
____________________________________________________________________________________________________________________________________
[1]https://github.com/weld/wildfly/tree/11.0.0.Alpha1-weld3
[2]https://github.com/weld/wildfly/blob/11.0.0.Alpha1-weld3/weld/subsystem...
[3]https://github.com/weld/wildfly/blob/11.0.0.Alpha1-weld3/weld/subsystem...
7 years, 7 months
