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.
8 years
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
8 years, 1 month
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...
8 years, 1 month
read-resource (even with include-runtime=false) iterates over dynamic children
by Jan Kalina
Hi,
I am just checking how wildfly controller handle dynamic resources because
issue (WFCORE-2691) where every recursive :read-resource (even with
include-runtime=false) asks parent resource for list of all dynamic
(runtime only)
children.
For example query:
*/subsystem=messaging-activemq:read-resource(include-runtime=false,recursive=true)*
will cause "server" resource (child of messaging-activemq) is asked for list
of all "core-address" (call *getChildren("core-address")*), even trough
they are not
displayed as part of operation result - only blank placeholder is printed:
*"core-address" => undefined,*
This is problem especially in case of new Elytron resources which allow to
browse
user identities using AS model - every :read-resource on root or every AS
boot
currently causes iterating over all users/identities available in all
concerned realms.
Is this design problem?
Is there some reason why should wildfly controller ask for all resource
children
even when they are ignored and not printed?
What do you think about it? How should be resources with dynamic children
handled?
Thanks,
Honza
8 years, 1 month
I want to contribute
by Антон Чураев
Hello!
Could you please help me with start contributing.
I want to contribute in WildFly project, but couldnot find any information
about ICLA/CCLA. Is it necessary to fill CLA form for starting contributing
to WildFly?
--
Best Regards, Anton Churaev
8 years, 1 month
Missing Credential Store integration in core Management
by Emmanuel Hugonnet
Hi,
Currently we store passwords for core management in various attributes.
With Elytron we can use a Credential Store to store those attributes values using a CredentialReference, which led to [1].
Investigating we have found the following attributes :
* SecretServerIdentityResourceDefinition.VALUE
* SSLServerIdentityResourceDefinition.KEYSTORE_PASSWORD KEY_PASSWORD
* TruststoreAuthenticationResourceDefinition.KEYSTORE_PASSWORD
* LocalAuthenticationResourceDefinition.DEFAULT_USER ALLOWED_USERS
* UserResourceDefinition.PASSWORD
* LdapConnectionResourceDefinition.SEARCH_CREDENTIAL
Did we miss attributes that could be alternative of CredentialReference ?
KEYSTORE_PASSWORD KEY_PASSWORD (in SSLServerIdentityResourceDefinition and TruststoreAuthenticationResourceDefinition) are using the
attribute definitions of KeystoreAttributes.
We could introduce the alternatives in those definition but that would impact SyslogAuditLogProtocolResourceDefinition.TlsKeyStore.
Cheers,
Emmanuel
[1]: https://issues.jboss.org/browse/WFCORE-2483
8 years, 1 month
The art, science, and torture of debugging test suite hangs
by David M. Lloyd
It's really a pain when you are developing a multifaceted change to the
application server and it hangs. Sometimes, if you're lucky, you can
stick jconsole on there and figure out at least a general idea of what
is going on, or reproduce the problem by running a test, a test class,
or a test module in isolation with debugging turned on. Sometimes
you're not so lucky, or sometimes the hang happens in the manualmode
test suite where you have to attach a debugger 9,000 times only to find
out that the hang doesn't happen when you do that.
I think we should introduce a new build profile which activates the
remote debugging port, but with suspend=n. This would allow entire full
test suite runs to be done while allowing debugger to be attached for
exploratory surgery in the event that something goes wrong. While it's
possible that having debugging activated might actually prevent the hang
you care about, at least there's a chance that something can be done.
--
- DML
8 years, 2 months
Approving PRs
by Brian Stansberry
If you review a PR and it’s good, please use the Git Hub review feature to say so instead of just leaving a comment. That makes the fact that someone has approved it visible at a glance in the PR queue[1] which is nice and saves opening the issue and scrolling through comments, CI run reports etc.
When you look at the files of the PR, e.g. [2], in the top right there is the green “Review Changes” button. Click it, select Approve, add a comment if you like, and hit Submit.
[1] https://github.com/wildfly/wildfly-core/pulls
[2] https://github.com/wildfly/wildfly-core/pull/2326/files
Thanks,
--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat
8 years, 2 months
Maven 3.5.0 - any known issues?
by Peter Palaga
Hi *,
as you may have noticed, Maven 3.5.0 has been released recently.
While having a colored console output is nice `mvn clean install
-DskipTests` works, are there any issues/reasons known already why Maven
3.5.0 should not be used for building WildFly & Co.?
Going through the relnotes [1] I found two potential sources of issues:
(1) Replaced Eclipse Aether with Maven Resolver - this will perhaps
change the resolution in some cases.
(2) Removed the artifact handler for ejb3 - do we use ejb3 packaging in
our code at all?
[1] https://maven.apache.org/docs/3.5.0/release-notes.html
Thanks,
Peter
8 years, 2 months
