wfly bin\*.conf.ps1 files question
by Rebecca Searls
I don't understand the reason for setting the (local) variable JAVA_OPTS
in the *.conf.ps1 files when the common.ps1 functions completely ignores
the local setting and always reads and uses the environment variable value.
The in-file comments leads the reader to believe he can override the system
env var and define a new JAVA_OPTS in the conf file which will be used by
the
calling script. Currently this is not true.
Can someone explain the intent here? Is this a bug or obsolete code that
should be removed?
6 years, 6 months
PR template check
by Martin Stefanko
Hi all,
I've created a tool [1] that validates the PR format. For now it checks the
title and the description for the required information configured by regex
expressions. It runs on my OS online and is configured in [2] on the master
branch.
The tool uses GH webhooks which needs to be set up in the targeting
repository and it requires the respective OAuth token, for now configured
through the OS secret.
This is the basic functionality, I can add more checks later (e.g., link
validity, number of commits). Any feedback is welcome.
[1] https://github.com/xstefank/tyr
[2] https://github.com/xstefank/test-repo
tyr.mp4
<https://drive.google.com/a/redhat.com/file/d/1QCeBSoviD2Xj9ycPjrH8cjwlbwE...>
Martin Stefanko
Software Engineer
JBoss Sustaining Engineering Team
Red Hat
6 years, 6 months
Generate WildFly BOMs as part of WildFly build
by Rostislav Svoboda
Hi team.
WildFly and WildFly core generate component-matrix as part of the build now.
https://issues.jboss.org/browse/WFLY-10365
We should also consider automated propagation of current WildFly master
component versions into WildFly BOMs - https://github.com/wildfly/boms. I'm
especially interested in https://github.com/wildfly/boms/tree/master/client
Currently, the sync is rather complicated (manual) and not at all intuitive
to implement.
Tomaz did great job on BOMs but with his departure nothing is really
happening in this area.
Possible approaches:
1) wildfly/boms project could consume the component matrix versions without
any required interaction besides just declaring version of WildFly
component matrix and then building wildfly/boms
2) generating -SNAPSHOT versions of WildFly BOMs as part of WildFly build
(going back I know) ++ publishing just the final BOMs to
https://github.com/wildfly/boms ?
Comments / suggestions ?
Regards.
Rostislav
6 years, 6 months
Docs & examples to update Hibernate ORM via the (existing) provisioning tool
by Sanne Grinovero
Hi all,
while I haven't looked at Galleon yet, we now have guidelines for
Hibernate users wishing to run the very latest Hibernate ORM (Search,
OGM) on WildFly:
- https://docs.jboss.org/hibernate/orm/5.3/topical/html_single/wildfly/Wild...
Some personal thoughts:
- the feature packs are awesome
- having slots (and multiple conflicting versions / layers) is
extremely useful and an advantage over Jigsaw which I hope we'll keep
having
- it's striking how much Gradle is easier, faster, and more powerful
than Maven: see my examples as I've included fully runnable Gradle
build scripts.
Please don't neglect Gradle's needs and users as it's thriwing in
other communities, while it feels a like second class citizen in the
WildFly ecosystem.
I've done my part by creating the Gradle WildFly Provisioning plugin
mentioned in the docs but I'd like to see more of such things :)
# Many feature packs!
We created lots of feature packs in the Hibernate community; on top of
the Hibernate ORM pack you can find:
Hibernate Search has been split in 5 fine-grained packs:
- https://docs.jboss.org/hibernate/search/5.10/reference/en-US/html_single/...
We also separated into independently released packs some of the
dependencies which people might want to use w/o necessarily pulling in
Hibernate bits:
Elasticsearch client drivers:
- https://github.com/hibernate/elasticsearch-client-jbossmodules
Extensions to the Elasticsearch integration which are specific for AWS
security requirements:
- https://github.com/hibernate/aws-v4-signer-java-jbossmodules
GSON packaged for WildFly:
- https://github.com/hibernate/gson-jbossmodules
Lucene, packaged for WildFly:
- https://github.com/hibernate/lucene-jbossmodules
Hibernate OGM is releasing soon as well and will double this list: one
pack for the main artifact plus one for each NoSQL technology's driver
and dialects.
# What's next?
Many of the above backs just require wildfly-core, yet Hibernate
ORM requires the "full server" as we need various subsystems such as
JTA and Datasources.
I hope you'll all make these fine-grained so that in the near
future the Hibernate ORM feature pack could declare a smaller
dependency set?
Also I'm looking forward to suggestions on what we need to do to
get these e.g. in some kind of catalogue / repository - I'm
understanding Galleon would be able to help with discovery?
Thanks,
Sanne
6 years, 6 months
galleon cli demo
by Jean-Francois Denise
Hi,
yesterday during management team meeting I have presented some of the
features (incubating...) that have been implemented in galleon cli
command line tool. The recording[1] contains the demo (a "fine grained"
provisioning of a web application), Q&A and Alexey demo of wildfly CLI
scripts generation from the same galleon cli tool. In case you have time
to watch the recording your feedbacks would be well appreciated.
Thank-you.
JF
[1]
https://bluejeans.com/playback/s/URuah7Xv77AvKmDhxz0kSuI6eLxXCDshXdJFG64q...
6 years, 6 months
Proposal to revert component-matrix change
by David Lloyd
I propose we revert the component-matrix change. This change is
ostensibly to help in the creation of a BOM for the client libraries
and other dependent projects; however, the cost has turned out to be
somewhat higher than expected.
IntelliJ seems to be unable to cope with dependency changes in the
project due to the use of import from the root POM. This means that
the entire project must be force-reimported from time to time to keep
dependencies up to date, and forgetting to do so can lead to
development issues and lost time.
Also, I've observed that Maven itself does not always correctly
resolve versions anymore, when you're building from a submodule. I
don't really know why this is the case but I suspect that it's due to
some algorithmic ambiguity when the dependency tree is not linear like
it used to be.
I think that if we need to generate some BOM for use by external
projects, it should be done as a separate step and artifact which
acquires versions from the parent. I believe we had it this way at
one point, didn't we?
Anyway I think this change didn't work out, and we should undo it
while it's still remotely possible. WDYT?
--
- DML
6 years, 6 months
JDK 11 Early Access build 12 available
by Rory O'Donnell
Hi Jason/Tomaz,
**JDK 11 EA build 12 , *****under both the GPL and Oracle EA licenses,
is now available at **http://jdk.java.net/11**. **
*
* Newly approved Schedule, status & features
o http://openjdk.java.net/projects/jdk/11/
* Release Notes:
o http://jdk.java.net/11/release-notes
* Summary of changes
o https://download.java.net/java/early_access/jdk11/12/jdk-11+12.html
*Notable changes in JDK 11 EA builds since last email:*
* Build 11 - see Release Notes for details.
o JDK-8201315 : SelectableChannel.register may be invoked while a
selection operation is in progress
* Build 10 - see Release Notes for details.
o JDK-8200149 : Removal of "com.sun.awt.AWTUtilities" class
o JDK-8189997 (not public) : Enhanced KeyStore Mechanisms
o JDK-8175075 (not public) : 3DES Cipher Suites Disabled
* Build 9: - see Release Notes for details.
o JDK-8200152 : KerberosString uses UTF-8 encoding by default
o JDK-8200458 : Readiness information previously recorded in
SelectionKey ready set not preserved
**
*Draft JEP: Deprecate pack200, unpack200 tools and related APIs. [1]
*
This draft JEP [2] proposes to deprecate the pack200 APIs and tools in
the JDK. As outlined in the JEP, the usefulness of this technology
have diminishing returns, the components using them are being removed
and connectivity speeds have improved by leaps and bounds,
since its inception. Feedback appreciated via
http://mail.openjdk.java.net/pipermail/jdk-dev
Regards,
Rory
[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001074.html
[2] https://bugs.openjdk.java.net/browse/JDK-8200752
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland
6 years, 7 months
How to secure Camel CXF endpoints with Elytron?
by Peter Palaga
Hi all, esp. Darran and Stuart,
We (WildFly Camel Team) have a request [1] to support securing Camel CXF
endpoints with Elytron and I am trying to figure out the best way to
achieve that.
= Current state
A Camel context is started by Weld during
Phase.INSTALL_CDI_VALIDATOR_FACTORY. This triggers a creation of the CXF
WS endpoint. To expose the endpoint on Undertow, we create an ad hoc
DeploymentInfo [2] with a context path requested by the Camel route [3].
To handle security, users are suggested to use CXF Interceptors, such as
JAASLoginInterceptor [4]. The JAASLoginInterceptor works well with
security domains defined in the legacy Security subsystem.
= The problem
A user wants to get rid of the legacy Security subsystem and use Elytron
instead.
= How to solve it
As Darran pointed out in the chat, there is no JAAS support in Elytron
and we thus cannot keep relying on JAASLoginInterceptor & Co.
I investigated how Elytron is integrated in Undertow subsystem (esp.
UndertowDeploymentInfoService) and I tried to do the same for our custom
DeploymentInfo in Camel subsystem. The key point was to obtain a
reference to securityFunction and apply it to the DeploymentInfo. In
this way our Camel CXF endpoints indeed got protected by an Elytron
security domain.
I have a dirty but working PoC [5] where I just copied parts of
UndertowDeploymentInfoService to a new CamelDynamicDeploymentService.
I'd like to try re-using UndertowDeploymentInfoService as a whole so
that I do not duplicate the security sensitive code. But before I do,
could you Darran, Stuart and others please approve the general idea or
eventually suggest something better?
Thanks,
-- Peter
[1] https://issues.jboss.org/browse/ENTESB-7959
[2]
https://github.com/wildfly-extras/wildfly-camel/blob/6.0.0/cxfhttp/src/ma...
[3]
https://github.com/wildfly-extras/wildfly-camel/blob/6.0.0/cxfhttp/src/ma...
[4]
https://github.com/wildfly-extras/wildfly-camel-examples/blob/6.0.0/camel...
[5] https://github.com/ppalaga/wildfly-camel/commits/ENTESB-7959.180430
6 years, 7 months
